-
Type:
Task
-
Resolution: Unresolved
-
Priority:
Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
Query Optimization
There are a number of operators (for example, $mod, $regex, $geoWithin) that are hard-coded as edge cases for being incompatible use btree index negation. When given a query of the form {$not: <leaf>} with one of those operators at the leaf, the root MatchExpression is not tagged as compatible with a btree index on the relevant field.
In many cases, $not queries are parsed into the form {$not: {$and: <>}}, but if there is only one predicate under the $and, the $and is optimized away. However, if the un-optimized, valid query ({$not: {$and: <leaf>}}, with one of the leaf examples from above) is passed to rateIndices, it instead recurses down the logical not-and chain here, and marks the leaf node as being compatible with a btree index on the relevant field.
This isn't a problem with running a query end-to-end since the PlanEnumerator does not generate any plans for a $not-$and query, so it falls back to collection scan, but it is misleading that the equivalent {$not:{$and: <leaf>}} and {$not: <leaf>} queries are tagged differently within rateIndices.
- is related to
-
SERVER-92193 Index Bounds Builder tries to build geo bounds using non-geo index
-
- Closed
-