Currently clauses in a $all will be evaluated in the order that they are provided to the query. This can lead to cases where a superset is being searched to find values that are contained within a smaller subset of the wanted values.
Consider trying to find all documents that have tags showing that they are an Italian and have a Michelin star within a collection of restaurants. There will be a large number of documents with the tag "Italian" but very few with the tag "Michelin".
If the tags are entered into the $all clause in alphabetical order, the search will take longer as the larger set of "Italian" documents must be searched again for the "Michelin" tag. If the tag order is reversed, then we search the smaller set of "Michelin" matching documents to find those who match "Italian".
The optimisation here would be to remove the dependency on the order of documents in an $all clause.
Changes in this case should handle situations where the entities within the $all clause are not simply fields, but also documents which may have several levels of depth.
- is duplicated by
-
SERVER-19999 $all with $elemMatch indexes first element regardless of predicate cardinality (regression)
- Closed
-
SERVER-20913 DateTime index ignored / horrible performance
- Closed
-
SERVER-3892 consider multiple candidate index scans, potentially with intersection, in cases of distinct ranges on a multikey index
- Closed
-
SERVER-12499 Unable to force predicate evaluation order with new query framework
- Closed
- is related to
-
SERVER-1000 $all with query optimizer
- Closed
- related to
-
SERVER-14264 Compound index on 2dsphere and datetime very slow in 2.6.1 and different result than in 2.4.10
- Closed
-
SERVER-12281 When choosing multikey index bounds, never choose a superset if a subset is available
- Backlog
-
SERVER-18364 Ensure non-negation predicates get chosen over negation predicates for multikey index bounds construction
- Closed