-
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
-