[SERVER-8454] Multi-key index prevents bounds being used for non-multi-key part Created: 06/Feb/13  Updated: 15/Feb/13  Resolved: 06/Feb/13

Status: Closed
Project: Core Server
Component/s: Index Maintenance
Affects Version/s: 2.2.0
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Colin Howe Assignee: Unassigned
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates SERVER-7959 Potentially unexpected scans with com... Closed
Related
related to SERVER-3173 Planner should use path-level multike... Closed
Operating System: ALL
Participants:

 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.



 Comments   
Comment by Colin Howe [ 06/Feb/13 ]

Minor note: this is causing us serious scan issues

Generated at Thu Feb 08 03:17:28 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.