[SERVER-3832] aggregation: early $sort should be optimized to use an index if possible Created: 13/Sep/11 Updated: 11/Jul/16 Resolved: 06/Jan/12 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Aggregation Framework |
| Affects Version/s: | None |
| Fix Version/s: | 2.1.0 |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Chris Westin | Assignee: | Mathias Stearn |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Participants: | |||||||||||||
| Description |
|
Similar to the optimization for an early $match, an early $sort should be able to use an index instead of sorting. |
| Comments |
| Comment by auto [ 06/Jan/12 ] |
|
Author: {u'login': u'cwestin', u'name': u'U-tellus\\cwestin', u'email': u'cwestin@10gen.com'}Message: |
| Comment by Chris Westin [ 16/Sep/11 ] |
|
This can use the same path used by having an early $match in the pipeline, which puts that into a query in order to use any existing indexes. In this case, instead, provide the specified sort key to the query in the appropriate way. |
| Comment by Chris Westin [ 13/Sep/11 ] |
|
We could do the initial release without this optimization (which doesn't seem like it would be a common use case), but linking just for tracking purposes. |