[SERVER-66437] Improve performance of IDhack plans in SBE Created: 12/May/22  Updated: 28/Mar/23

Status: Open
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major - P3
Reporter: Anton Korshunov Assignee: Backlog - Query Execution
Resolution: Unresolved Votes: 0
Labels: pm2697-m3
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File classicidhack.svg     File sbefastidhack.svg     File sbeidhack.svg    
Issue Links:
Depends
depends on SERVER-67610 Use RuntimeEnvironment for index key ... Closed
is depended on by SERVER-67610 Use RuntimeEnvironment for index key ... Closed
Duplicate
Related
related to SERVER-66435 Always use classic engine for IDhack ... Closed
is related to SERVER-69751 Investigate SBE Linkbench regressions Closed
Assigned Teams:
Query Execution
Sprint: QE 2022-09-19, QE 2022-10-03, QE 2022-10-17
Participants:
Story Points: 2

 Description   

As part of PM-2371 we collected a perf profile for the SBE engine with the new SBE plan cache. Based on the collected results it appeared that the classic engine is still ~20% faster when executing IDhack plans and the plan cache project couldn't close this gap. We still spend a lot of time recovering the plan from the cache and preparing for execution in SBE. The classic engine does it dead simple but exercising through a fast path of constructing a plan consisting of a single stage. We need to find a way to allow the SBE engine to compete on this type of queries with the classic engine.



 Comments   
Comment by Mihai Andrei [ 28/Mar/23 ]

Reopening this and moving it to pm-3243

Comment by Anna Wawrzyniak [ 03/Oct/22 ]

We have discussed the following options:

a) fallback to classic ID hack

b) use sbe "franken id ID hack"

c) use prepared pool for ID hack eligible queries

d) use prepared pool for wider range of queries

Between options a),b),c) we decided that option a) is most appropriate in the shortterm. See slack discussion: https://mongodb.slack.com/archives/C03FR20DLVD/p1664646211383049

 

Option d) is still viable, but is was deemed out of scope of Improve SBE performance epic. The following ticket tracks that work https://jira.mongodb.org/browse/SERVER-69774

Comment by Nikita Lapkov (Inactive) [ 08/Sep/22 ]

Sorry for the ping-pong, assigning this back to Mihai per our discussion on ABT meeting.

Comment by Kyle Suarez [ 02/Sep/22 ]

Assigning to the venerable nikita.lapkov@mongodb.com to drive this task for this sprint while Mihai is on vacation.

Comment by Anna Wawrzyniak [ 11/Aug/22 ]

https://docs.google.com/document/d/1iYWU2N8230N0ipSIXeRkb8lyH-_qZB-o7ucuADCSZCA/edit?usp=sharing

It looks like changed in the [Eric's prototype|http://example.com] still result in -10% regression compared to classic. Even with franken idhack with single stage plan, similar to classic idhack, we still have -5% regression.

 

 

Comment by Githook User [ 30/Jun/22 ]

Author:

{'name': 'Eric Cox', 'email': 'eric.cox@mongodb.com', 'username': 'ericox'}

Message: SERVER-66437 Refactor IndexScanStage to take seek keys as EExpressions
Branch: master
https://github.com/mongodb/mongo/commit/a372be3c03a6ab0ad96e62c6c241514b6ed699cb

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