|
I think this has been resolved as part of the query system rewrite for 2.6 (see SERVER-10026). An equality query against an indexed array does not have to scan the entire array, but rather infers that the document matches due to the presence of the index key:
> db.version()
|
3.1.0-pre-
|
> t.drop()
|
true
|
> t.ensureIndex({a: 1})
|
{
|
"createdCollectionAutomatically" : true,
|
"numIndexesBefore" : 1,
|
"numIndexesAfter" : 2,
|
"ok" : 1
|
}
|
> t.insert({_id: 1, a: [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]})
|
WriteResult({ "nInserted" : 1 })
|
> t.find({a: 3}).explain()
|
{
|
"queryPlanner" : {
|
"plannerVersion" : 1,
|
"namespace" : "test.t",
|
"indexFilterSet" : false,
|
"parsedQuery" : {
|
"a" : {
|
"$eq" : 3
|
}
|
},
|
"winningPlan" : {
|
"stage" : "FETCH",
|
"inputStage" : {
|
"stage" : "IXSCAN",
|
"keyPattern" : {
|
"a" : 1
|
},
|
"indexName" : "a_1",
|
"isMultiKey" : true,
|
"direction" : "forward",
|
"indexBounds" : {
|
"a" : [
|
"[3.0, 3.0]"
|
]
|
}
|
}
|
},
|
"rejectedPlans" : [ ]
|
},
|
"serverInfo" : {
|
"host" : "dstorch-desktop",
|
"port" : 27017,
|
"version" : "3.1.0-pre-",
|
"gitVersion" : "d8628625507b7a6927f21b1f1f91d68201fe4030"
|
},
|
"ok" : 1
|
}
|
Note in the explain output above that there is no filter on the FETCH stage. This indicates that the matcher is never used to match the full array against the query predicate.
Resolving as a duplicate of SERVER-10026.
|