Details
-
Bug
-
Status: Closed
-
Major - P3
-
Resolution: Duplicate
-
2.6.0-rc1
-
None
-
Query Optimization
-
ALL
-
(copied to CRM)
Description
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);
|
Attachments
Issue Links
- is duplicated 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
-