-
Type: Improvement
-
Resolution: Unresolved
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: Querying
-
None
-
Query Optimization
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 related to
-
SERVER-94087 Avoid using a PROJECTION_COVERED stage with DISTINCT_SCAN
- Open
-
SERVER-93059 Remove projection for multiplanning in case of distinct command
- Closed