SERVER-3892 and SERVER-16042 describe a limitation of our plan enumerator which we have only partially fixed.

When a query has two different predicates on the same array-valued field, there are several ways we could use a multikey index to answer the query:

• IXSCAN the first predicate and FETCH
• IXSCAN the second predicate and FETCH
• an index intersection plan (if other conditions are met)

Originally, we would only generate one of these plans, by picking one of the predicates (somewhat arbitrarily) to index. In SERVER-16042 we fixed it by generating all the alternatives, but only when the field in question is the leading field of the index. Possibly the reason we only partially fixed it was to avoid an explosion in the number of possible plans we enumerate.

For example, this index and query considers both possible index bounds:

db.c.drop()
db.c.insert({arr: [1,2]})
db.c.createIndex({arr: 1})
db.c.find({$and: [ {arr:{$lte:0}}, {arr:{$gte:99}} ]}).explain()

While this index and query only considers one plan:

db.c.drop()
db.c.insert({arr: [1,2]})
db.c.createIndex({x: 1, arr: 1})
db.c.find({$and: [ {x:{$eq:1}}, {arr:{$lte:0}}, {arr:{$gte:99}} ]}).explain()