The current state of affairs is that the normal engine selection rules are used when deciding whether SBE or the classic engine should be used for queries issued recursively by DocumentSourceLookup. This has proven to be problematic for performance, especially for some of the TPC-H benchmarks which we run. In particular, the auto-parameterization rules for the SBE plan cache differ from those for the classic engine's cache – join predicates expressed using $expr will not benefit from plan caching on the inner side, resulting in a substantial performance regression (especially when the plan cache has not yet been populated).
The work for this ticket is to ensure that the classic engine is always used on the inner side of a DocumentSourceLookup. (The cases in which $lookup is fully pushed down to the SBE layer will not be affected by this change.) This will likely immediately restore performance for a number of TPC-H queries. It also seems like a useful simplification in that we will not support this relatively complicated "hybrid plans" scenario in SBE until we are confident that basic cases are performing well.
- is related to
-
SERVER-79424 Support using SBE for $search inside $lookup/$unionWith
- Closed
- related to
-
SERVER-88941 Index query settings changes $graphLookup inner pipeline's engine
- Closed
-
SERVER-69112 Allow SBE to be used on the inner side of a DocumentSourceLookup
- Backlog
-
SERVER-69188 Disable use of SBE on the inner side of DocumentSourceLookup when the inner side is sharded
- Backlog