Details
-
Bug
-
Resolution: Duplicate
-
Major - P3
-
None
-
2.2.0
-
None
-
ALL
Description
db.multikey.insert({accounts:[1, 2], day:ISODate('2013-01-01')})
|
db.multikey.insert({accounts:[1, 2], day:ISODate('2013-01-02')})
|
db.multikey.insert({accounts:[1, 2], day:ISODate('2013-01-03')})
|
db.multikey.ensureIndex({accounts:1, day:1})
|
db.multikey.find({accounts:1, day:{$gte: ISODate('2013-01-01'), $lt: ISODate('2013-01-02')}}).explain()
|
{
|
"cursor" : "BtreeCursor accounts_1_day_1",
|
"isMultiKey" : true,
|
"n" : 1,
|
"nscannedObjects" : 3,
|
"nscanned" : 3,
|
"nscannedObjectsAllPlans" : 3,
|
"nscannedAllPlans" : 3,
|
"scanAndOrder" : false,
|
"indexOnly" : false,
|
"nYields" : 0,
|
"nChunkSkips" : 0,
|
"millis" : 0,
|
"indexBounds" : {
|
"accounts" : [
|
[
|
1,
|
1
|
]
|
],
|
"day" : [
|
[
|
ISODate("2013-01-01T00:00:00Z"),
|
ISODate("292278995-01--2147483647T07:12:56.808Z")
|
]
|
]
|
},
|
"server" : "vagrant-ubuntu:27017"
|
}
|
I would have expected the upper bound on day to still be sane - day is not multivalue, only accounts is. Alternatively, I would expect the query not to scan so many documents and stop as soon as it finds one that doesn't match the query.
Attachments
Issue Links
- duplicates
-
SERVER-7959 Potentially unexpected scans with compound indexes when some fields are multikey
-
- Closed
-
- related to
-
SERVER-3173 Planner should use path-level multikey info to generate covered plans when possible
-
- Closed
-