Details
-
Bug
-
Resolution: Duplicate
-
Major - P3
-
None
-
None
-
None
-
ALL
Description
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)
Attachments
Issue Links
- duplicates
-
SERVER-3173 Planner should use path-level multikey info to generate covered plans when possible
-
- Closed
-