-
Type: Bug
-
Resolution: Duplicate
-
Priority: Major - P3
-
None
-
Affects Version/s: 2.6.0-rc1
-
Component/s: Querying
-
Query Optimization
-
ALL
-
(copied to CRM)
The plan enumerator outputs 6 plans for the below query (one for each of the first 6 six indexes created), none of which use the 7th / most optimal index {a: 1, h: 1}.
db.foo.ensureIndex({a: 1, b: 1}); db.foo.ensureIndex({a: 1, c: 1}); db.foo.ensureIndex({a: 1, d: 1}); db.foo.ensureIndex({a: 1, e: 1}); db.foo.ensureIndex({a: 1, f: 1}); db.foo.ensureIndex({a: 1, g: 1}); db.foo.ensureIndex({a: 1, h: 1}); for (var i = 0; i < 10000; i++) { db.foo.insert({a: 1, h: i}); } // Below assertion fails with "Error: [1] != [10000] are not equal" assert.eq(1, db.foo.find({a: 1, h: 1}).explain().nscanned);
- duplicates
-
SERVER-80233 Implement index prefix heuristic
- Closed
- is fixed by
-
SERVER-80233 Implement index prefix heuristic
- Closed
- is related to
-
SERVER-16350 Wrong index choice when request contains _id in query + sort command
- Closed
-
SERVER-20616 Plan ranker sampling from the beginning of a query's execution can result in poor plan selection
- Backlog
-
SERVER-21697 Plan ranking should take query and index keys into consideration for breaking ties
- Closed
-
SERVER-40844 Better tie breaking of "perfect" indexes
- Closed
- related to
-
SERVER-24312 Mongo Query Taking Lot of Time Selecting Index
- Closed