-
Type:
Improvement
-
Resolution: Unresolved
-
Priority:
Major - P3
-
None
-
Affects Version/s: None
-
Component/s: Querying
-
None
-
Query Optimization
-
None
-
None
-
None
-
None
-
None
-
None
-
None
Covered plans used to answer the distinct command currently have a PROJECTION stage as the root:
> db.c.drop();
> db.c.createIndex({a: 1});
> db.c.explain().distinct("a");
{
"queryPlanner" : {
"plannerVersion" : 1,
"namespace" : "test.c",
"indexFilterSet" : false,
"parsedQuery" : {
},
"winningPlan" : {
"stage" : "PROJECTION",
"transformBy" : {
"_id" : 0,
"a" : 1
},
"inputStage" : {
"stage" : "DISTINCT_SCAN",
"keyPattern" : {
"a" : 1
},
"indexName" : "a_1",
"isMultiKey" : false,
"multiKeyPaths" : {
"a" : [ ]
},
"isUnique" : false,
"isSparse" : false,
"isPartial" : false,
"indexVersion" : 1,
"direction" : "forward",
"indexBounds" : {
"a" : [
"[MinKey, MaxKey]"
]
}
}
},
"rejectedPlans" : [ ]
},
"serverInfo" : {
"host" : "dstorch",
"port" : 27017,
"version" : "0.0.0",
"gitVersion" : "unknown"
},
"ok" : 1
}
This projection stage is not actually needed, since the PlanExecutor can produce the distinct values from WorkingSetMembers in RID_AND_IDX state.
- is duplicated by
-
SERVER-94087 Avoid using a PROJECTION_COVERED stage with DISTINCT_SCAN
-
- Closed
-
- is related to
-
SERVER-93059 Remove projection for multiplanning in case of distinct command
-
- Closed
-
-
SERVER-94087 Avoid using a PROJECTION_COVERED stage with DISTINCT_SCAN
-
- Closed
-