[SERVER-69103] Disable use of SBE on the inner side of DocumentSourceLookup Created: 23/Aug/22  Updated: 29/Oct/23  Resolved: 26/Aug/22

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: 6.0.2, 6.1.0-rc1, 6.2.0-rc0

Type: Task Priority: Major - P3
Reporter: David Storch Assignee: David Storch
Resolution: Fixed Votes: 0
Labels: pm2697-m2
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Depends
Problem/Incident
Related
related to SERVER-69112 Allow SBE to be used on the inner sid... Backlog
related to SERVER-69188 Disable use of SBE on the inner side ... Backlog
is related to SERVER-79424 Support using SBE for $search inside ... Closed
Backwards Compatibility: Fully Compatible
Backport Requested:
v6.1, v6.0
Sprint: QE 2022-08-22, QE 2022-09-05
Participants:
Linked BF Score: 135

 Description   

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.



 Comments   
Comment by Githook User [ 31/Aug/22 ]

Author:

{'name': 'David Storch', 'email': 'david.storch@mongodb.com', 'username': 'dstorch'}

Message: SERVER-69103 Always use the classic engine on the inner side of DocumentSourceLookup or $graphLookup

(cherry picked from commit 331e44c65a4806d5d619ec4424380b34b071c463)
Branch: v6.0
https://github.com/mongodb/mongo/commit/0d06938ab1de563d58fc1974352ead554e28ef1f

Comment by Githook User [ 31/Aug/22 ]

Author:

{'name': 'David Storch', 'email': 'david.storch@mongodb.com', 'username': 'dstorch'}

Message: SERVER-69103 Always use the classic engine on the inner side of DocumentSourceLookup or $graphLookup

(cherry picked from commit 331e44c65a4806d5d619ec4424380b34b071c463)
Branch: v6.1
https://github.com/mongodb/mongo/commit/fd671b6b1e3272fb741b7dde16b2b9f1499b148f

Comment by Githook User [ 26/Aug/22 ]

Author:

{'name': 'David Storch', 'email': 'david.storch@mongodb.com', 'username': 'dstorch'}

Message: SERVER-69103 Always use the classic engine on the inner side of DocumentSourceLookup or $graphLookup
Branch: master
https://github.com/mongodb/mongo/commit/331e44c65a4806d5d619ec4424380b34b071c463

Comment by David Storch [ 26/Aug/22 ]

I filed SERVER-69188 as an optional improvement to this work to make similar behavior apply across shards in the case of sharded $lookup.

Generated at Thu Feb 08 06:12:35 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.