-
Type:
Improvement
-
Resolution: Duplicate
-
Priority:
Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
None
-
Query Optimization
-
None
-
None
-
None
-
None
-
None
-
None
-
None
For queries that result in index bounds [MinKey, MaxKey], we see "FETCH" and "IXSCAN" stages instead of the "COLLSCAN" stage. Example query and explain output are given below:
db.foo.find({$expr: {$or: [{$gt: ["$_id", 3]}, {$lt: ["$_id", 5]}]}}).explain()
...
"winningPlan" : {
"isCached" : false,
"stage" : "FETCH",
"filter" : {
"$expr" : {
"$or" : [
{
"$gt" : [
"$_id",
{
"$const" : 3
}
]
},
{
"$lt" : [
"$_id",
{
"$const" : 5
}
]
}
]
}
},
"inputStage" : {
"stage" : "IXSCAN",
"keyPattern" : {
"_id" : 1
},
"indexName" : "_id_",
"isMultiKey" : false,
"isUnique" : true,
"isSparse" : false,
"isPartial" : false,
"indexVersion" : 2,
"direction" : "forward",
"indexBounds" : {
"_id" : [
"[MinKey, MaxKey]"
]
}
}
},
"rejectedPlans" : [ ]
}
- duplicates
-
SERVER-13065 Consider a collection scan even if indexed plans are available
-
- Backlog
-
- is related to
-
SERVER-98479 Revisit full covered index scans as collection scan alternative
-
- Backlog
-
-
SERVER-102271 Create a property-based test to assert query planner does not generate plans that are never optimal
-
- Backlog
-
- related to
-
SERVER-13065 Consider a collection scan even if indexed plans are available
-
- Backlog
-
-
SERVER-13197 Tighten index bounds and allow compound index to be chosen when predicate on leading field is not provided
-
- Backlog
-