-
Type: Improvement
-
Resolution: Unresolved
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
None
-
Query Optimization
-
QO 2024-02-05, QO 2024-02-19, QO 2024-03-04, QO 2024-03-18, QO 2024-04-01, QO 2024-04-15, QO 2024-04-29, QO 2024-05-13, QO 2024-05-27
SERVER-84338 disabled the MatchExpression $or->$in rewrite when the equality predicates are parameters. For example (in pseudo-MQL), {$or: [{foo: p1}, {foo: p2}]} cannot be rewritten to {foo: {$in: [p1, p2]}} because InMatchExpression only allows the entire $in operand to be a single parameter. This fixed an edge case in the subplanner which resulted in construction of a residual predicate with incorrect autoparameterization behavior.
Another solution to that problem is to introduce a new MatchExpression or modify the representation of InMatchExpression parameters in order to allow an InMatchExpression to contain an array of parameters and literals.
Some questions we'd need to answer to do this ticket:
- Is the subplanner case in
SERVER-84338the only one where an array of parameters in $in would occur? - If so, is the complexity added by implementing this ticket worth the potential performance gain?
- is related to
-
SERVER-84338 Top level $or queries may lead to invalid SBE plan cache entry which returns wrong results
- Closed
- related to
-
SERVER-83712 Do not add $in length to plan cache key if there is no sort
- Closed