-
Type: Improvement
-
Resolution: Unresolved
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: Aggregation Framework
-
Query Optimization
-
Fully Compatible
-
QuInt 8 08/28/15, Query 2019-06-17, Query 2019-07-01, Query 2019-07-15, Query 2019-07-29, Query 2019-08-12
-
(copied to CRM)
Copied from SERVER-4961:
On sharded environment, using early grouping, besides the use of an index, it would be nice that we be able to avoid the mongos regrouping process.
I'll try to explain that:
* result_node1: [ { id: "value1", totalcount: 50 }, { id: "value2", totalcount: 100 }, ] * result_node2: [ { id: "value1", totalcount: 60 } ]
The real results(after mongos regroup) must looks like:
[ { id: "value1", totalcount: 110 }, { id: "value2", totalcount: 100 }, ]
But, in some cases, mongos regrouping process is nonsense since the grouping key is same as sharding key. So, never got same group key from different shards.
So, the prior example, now looks like:
* result_node1: [ { id: "value1", totalcount: 110 } ] * result_node2: [ { id: "value2", totalcount: 100 } ]
The real results must looks like:
[ { id: "value1", totalcount: 110 }, { id: "value2", totalcount: 100 }, ]
So, the point is mongos regrouping process is a waste of time when you group using same key as sharding key.
- depends on
-
SERVER-42160 $group stages that use a DISTINCT_SCAN do not use a SHARDING_FILTER on sharded collections
- Backlog
-
SERVER-41750 Refactor renamedPaths() helpers to support renames in either direction
- Closed
- is duplicated by
-
SERVER-22912 Query Optimizer
- Closed
- is related to
-
SERVER-27115 Track fields renamed by $project in aggregation for index consideration
- Closed
-
SERVER-28942 sort by shard key or prefix of shard key may not require merge before group
- Backlog
-
SERVER-55200 DISTINCT_SCAN not used for $sort+$match+$group+$first on sharded collection
- Backlog
- related to
-
SERVER-56583 Push $setWindowFields to shards when shards contain whole partitions
- Backlog