-
Type:
Bug
-
Resolution: Duplicate
-
Priority:
Major - P3
-
None
-
Affects Version/s: None
-
Component/s: Diagnostics, Performance
-
None
-
ALL
-
None
-
None
-
None
-
None
-
None
-
None
-
None
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
-