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