-
Type:
Improvement
-
Status: Open
-
Priority:
Major - P3
-
Resolution: Unresolved
-
Affects Version/s: None
-
Fix Version/s: Backlog
-
Component/s: Aggregation Framework
-
Labels:
-
Backwards Compatibility:Fully Compatible
-
Epic Link:
-
Sprint:Query 10 (02/22/16), Query 11 (03/14/16), Query 12 (04/04/16)
-
Case:
If the input to a $group is sorted by the _id, then only one bucket needs to be maintained at a time. This will reduce memory requirements significantly.
We can examine the _id and take advantage of this if we can force an index scan on the key, if there are no intervening pipeline operations that would affect the results.
- depends on
-
SERVER-4566 In new aggregation framework, $sort, $limit in the pipeline seems loading all the matched data into memory. When we tried to improve the performance by leveraging multi thread aggregation, this makes it much slower than single thread
-
- Closed
-
- is depended on by
-
SERVER-5795 Very Poor Performances
-
- Closed
-
- is duplicated by
-
SERVER-11447 aggregation can sort using index to speed up group of an indexed field
-
- Closed
-
-
SERVER-37242 $group on sort key (after $sort) could be optimized to avoid blocking
-
- Closed
-
-
SERVER-21502 $group using index
-
- Closed
-
- is related to
-
SERVER-447 new aggregation framework
-
- Closed
-
-
SERVER-29444 Take advantage of indexes in common aggregation pipelines
-
- Open
-
-
SERVER-9507 Optimize $sort+$group+$first pipeline to avoid full index scan
-
- Closed
-
- related to
-
SERVER-4961 $group is taking 2x as long as collection.group()
-
- Closed
-
-
SERVER-23477 Aggregation's streaming $group should become blocking when it evaluates an array field in the _id
-
- Closed
-
-
SERVER-5361 early $group should provide a hint to use an index matching the group key
-
- Closed
-
-
SERVER-20066 Query planner should consider index scans on empty query predicates
-
- Closed
-