[SERVER-20551] sort on multikey index after $elemMatch projection Created: 22/Sep/15 Updated: 07/Apr/23 Resolved: 23/Sep/15 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Querying |
| Affects Version/s: | 2.6.5 |
| Fix Version/s: | None |
| Type: | Question | Priority: | Major - P3 |
| Reporter: | Evan Altman | Assignee: | Unassigned |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||
| Description |
|
I'm attempting a descending sort on a subdocument field which is indexed. Without any projection on my query, it appears that my documents use the multikey index's highest value as the sort key. This makes sense to me. However, when I employ $elemMatch to return just one subdocument, per document, the sort key still appears to be the highest value of the multikey index, regardless of whether its subdocument has been projected out. Is there a way to use a multikey indexed field, but respect the $elemMatch? Example: { "_id": "a", "values":[ {"test": 4}, {"test": 1, "keep": true} ] } , {"test": 2, "keep": true}] } |
| Comments |
| Comment by Evan Altman [ 25/Sep/15 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
I realized that because the question contains $elemMatch, there is no answer. That said, using $unwind in the aggregation pipeline should technically allow me to do what I want (albeit not using find().sort() ). | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by J Rassi [ 23/Sep/15 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
One more thing: I forgot to directly address your original question "Is there a way to use a multikey indexed field, but respect the $elemMatch?", so I thought to follow up. No, unfortunately the query subsystem always constructs query plans such that the sort logically happens "before" the projection. This provides clean semantics for such use cases as sorting on a field that is projected out of the document (e.g. db.collection.find({}, {a: 0}).sort({a: 1}); if the projection happened "before" the sort, then each document would generate a null key and the result would be unsorted. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by J Rassi [ 23/Sep/15 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Hi, The results that you've posted are consistent with the server's sort semantics. For sorting on an array in the case of an empty query predicate, the server picks the minimum element of the array as the document's sort key for ascending sorts, and the maximum value of the array as the document's sort key for descending sorts. Please see my comment at As a result, I'm closing this ticket with resolution "Works as Designed". If you're curious, see also the related ticket ~ Jason Rassi | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Evan Altman [ 22/Sep/15 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Hey Rassi,
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by J Rassi [ 22/Sep/15 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Hi, Could you please provide the output of running explain(true) against both queries? Thanks. ~ Jason Rassi | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Evan Altman [ 22/Sep/15 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
should return documents in order "a", "b" I would expect
to return documents in order "b", "a". |