-
Type:
Improvement
-
Resolution: Gone away
-
Priority:
Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
QO 2022-02-07
-
None
-
3
-
None
-
None
-
None
-
None
-
None
-
None
-
None
Due to the changes in SERVER-19402, it is no longer correct for a multikey index scan to provide a non-blocking sort. Therefore, in general, a multikey index should not be used for operations if it is only eligible for consideration based on the requested sort.
This appears to already be the case for aggregations as a COLLSCAN is performed:
> db.demo.explain().aggregate([{$sort:{x:1}}])
{
"stages" : [
{
"$cursor" : {
"query" : {
},
"queryPlanner" : {
"plannerVersion" : 1,
"namespace" : "test.demo",
"indexFilterSet" : false,
"parsedQuery" : {
},
"queryHash" : "8B3D4AB8",
"winningPlan" : {
"stage" : "COLLSCAN",
"direction" : "forward"
},
"rejectedPlans" : [ ]
}
}
},
{
"$sort" : {
"sortKey" : {
"x" : 1
}
}
}
],
"ok" : 1
}
However find commands appear to generate a plan with "[MinKey, MaxKey]" index bounds:
> db.demo.explain().find().sort({x:1})
{
"queryPlanner" : {
"plannerVersion" : 1,
"namespace" : "test.demo",
"indexFilterSet" : false,
"parsedQuery" : {
},
"queryHash" : "B7791BAD",
"winningPlan" : {
"stage" : "SORT",
"sortPattern" : {
"x" : 1
},
"inputStage" : {
"stage" : "SORT_KEY_GENERATOR",
"inputStage" : {
"stage" : "FETCH",
"inputStage" : {
"stage" : "IXSCAN",
"keyPattern" : {
"x" : 1
},
"indexName" : "x_1",
"isMultiKey" : true,
"multiKeyPaths" : {
"x" : [
"x"
]
},
"isUnique" : false,
"isSparse" : false,
"isPartial" : false,
"indexVersion" : 2,
"direction" : "forward",
"indexBounds" : {
"x" : [
"[MinKey, MaxKey]"
]
}
}
}
}
},
"rejectedPlans" : [ ]
},
"serverInfo" : {
"host" : "Chriss-MacBook-Pro.local",
"port" : 27017,
"version" : "4.1.4",
"gitVersion" : "2f4b5918497b09a226a3ec5dcff930edd52ea1e9"
},
"ok" : 1
}