As of the changes in SERVER-19402, a multikey field of an index cannot be used to provide a non-blocking sort. This is not correctly enforced in the explodeForSort() path of the planner's sort analysis phase. As a result, the planner produces an incorrect plan which does not sort array fields correctly according to the new semantics described in SERVER-19402:
> db.c.find(); { "_id" : 0, "a" : [ { "b" : 0, "c" : 1 }, { "b" : 1, "c" : 2 } ] } { "_id" : 1, "a" : [ { "b" : 0, "c" : 2 }, { "b" : 1, "c" : 0 } ] } { "_id" : 2, "a" : [ { "b" : 0, "c" : 0 }, { "b" : 1, "c" : 1 } ] } > db.c.createIndex({"a.b": 1, "a.c": 1}) { "createdCollectionAutomatically" : false, "numIndexesBefore" : 2, "numIndexesAfter" : 2, "note" : "all indexes already exist", "ok" : 1 } // The sort order is incorrect since the _id:1 document should sort before _id:0. > db.c.find({"a.b": 0 }).sort({"a.c": 1 }); { "_id" : 2, "a" : [ { "b" : 0, "c" : 0 }, { "b" : 1, "c" : 1 } ] } { "_id" : 0, "a" : [ { "b" : 0, "c" : 1 }, { "b" : 1, "c" : 2 } ] } { "_id" : 1, "a" : [ { "b" : 0, "c" : 2 }, { "b" : 1, "c" : 0 } ] }
- is related to
-
SERVER-19402 Change semantics of sorting by array fields in find and aggregate
- Closed