-
Type: Bug
-
Resolution: Duplicate
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: Diagnostics, Performance
-
None
-
ALL
I've noticed that queries on a multiKey index are never indexOnly. Is that true? Seems odd.
For example if you set up a table as follows:
db.test.drop(); db.test.ensureIndex({single: 1, multi: 1}); db.test.insert({single: 'a', multi: [1,2,3]}); db.test.insert({single: 'b', multi: [2,3,4]}); db.test.insert({single: 'a', multi: [3,4,5]}); db.test.insert({single: 'b', multi: [4,5,6]});
Then querying on 'single' with a readset of just 'single' still gives indexOnly: false, even though the required data should certainly be available in the index:
> db.test.find({single: 'a'}, {single: 1, _id: 0}).explain() { "cursor" : "BtreeCursor single_1_multi_1", "isMultiKey" : true, "n" : 2, "nscannedObjects" : 6, "nscanned" : 6, "nscannedObjectsAllPlans" : 6, "nscannedAllPlans" : 6, "scanAndOrder" : false, "indexOnly" : false, "nYields" : 0, "nChunkSkips" : 0, "millis" : 0, "indexBounds" : { "single" : [ [ "a", "a" ] ], "multi" : [ [ { "$minElement" : 1 }, { "$maxElement" : 1 } ] ] } }
I don't know if this is an actual performance issue or just a problem with explain().
(Note that this was originally a post in the Google Group, where Max Schireson said I should file a bug: https://groups.google.com/forum/?fromgroups=#!topic/mongodb-user/QsZFS4nddHo)
- duplicates
-
SERVER-3173 Planner should use path-level multikey info to generate covered plans when possible
- Closed