As described in SERVER-36393 there are cases where we fail to enumerate some interesting plans because we limit the number of plans we generate for a contained $or. While not a complete solution, one suggestion for a workaround on that ticket was to add a way to enumerate the children of the $or in a different "more interesting" order. To quote:
Asya points out that our plan enumeration code might fall over like this less if it changes its enumeration strategy from something like:
A, A, A
A, A, B
A, A, C
...
To something like
A, A, A
B, B, B
C, C, C
...
This is a heuristic that might help us to force the plan selection code to consider the best index in more cases, short of a more complete solution.
This ticket tracks the work to implement that solution.
- is related to
-
SERVER-36393 Contained $or pushdown optimization can cause internalQueryEnumerationMaxOrSolutions to be exceeded
- Backlog
-
SERVER-74893 Change default enumeration strategy for planning $or queries
- Closed
- related to
-
SERVER-83091 $or query can trigger an infinite loop during plan enumeration
- Closed