-
Type:
Bug
-
Resolution: Duplicate
-
Priority:
Major - P3
-
None
-
Affects Version/s: 2.2.0
-
Component/s: Index Maintenance
-
None
-
ALL
-
None
-
None
-
None
-
None
-
None
-
None
-
None
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.
- 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
-