[SERVER-66816] Experiment: Use ABT lowering in the SBE stage builders to produce more efficient plans Created: 26/May/22  Updated: 13/Sep/22  Resolved: 16/Aug/22

Status: Closed
Project: Core Server
Component/s: Query Execution
Affects Version/s: None
Fix Version/s: None

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

Attachments: File abtmulticomponent.svg     File abtsinglecomponent.svg     File classicmulticomponent.svg     File classicsinglecomponent.svg    
Issue Links:
Related
related to SERVER-68969 Replace TraverseStage with traverseF ... Closed
Sprint: QE 2022-07-11, QE 2022-07-25, QE 2022-08-08, QE 2022-08-22
Participants:

 Description   

We have observed that the way we translate certain MQL constructs to SBE in the SBE stage builders can be inefficient. ABT lowering will do things fundamentally differently in that it produces plans with traverse expressions rather than traverse plan stages. These expressions will compile to bytecode and be executed by the VM which has the potential to be faster than executing a complex tree of sbe::PlanStage objects.

As an experiment, we should try using the ABT lowering code from the Bonsai optimizer POC to build SBE plans. We can start with MatchExpressions: convert MatchExpression to ABT, then convert the ABT to an EExpression which can compile to bytecode. It would also be interesting to do the same thing for projections, especially simple inclusion/exclusion projections which are common for find commands.



 Comments   
Comment by Drew Paroski [ 18/Aug/22 ]

I have a diff for SERVER-68969 that I put up for review: https://github.com/10gen/mongo/pull/7036/files

This diff improves the SBE stage builder to use traverseF() in most cases instead of TraverseStage.

Just wanted to share as it may be relevant to some of the folks following along with this ticket (SERVER-66816).

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