[SERVER-69362] Investigate if we can avoid save/restore in UpdateStage Created: 01/Sep/22  Updated: 09/May/23

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

Type: Improvement Priority: Major - P3
Reporter: Jordi Olivares Provencio Assignee: Backlog - Query Execution
Resolution: Unresolved Votes: 0
Labels: query-perf-candidate
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by SERVER-69396 Modify time-series inserts to use dam... Blocked
Assigned Teams:
Query Execution
Participants:

 Description   

Right now in UpdateStage we perform a PlanStage::saveState before making changes and a PlanStage::restoreState afterwards. These operations can potentially be expensive and costly.

We should investigate whether we can omit them in some cases. If not, then we should leave a comment explaining why we can't do that as it is not clear why they are needed.



 Comments   
Comment by Kyle Suarez [ 25/Apr/23 ]

Since Storage Execution kicked this to Query Execution, I'm going to send this to the triage queue and remove it from the "7.1 Desired StorEx Tickets" project. jordi.olivares-provencio@mongodb.com / louis.williams@mongodb.com / henrik.edin@mongodb.com let us know if this was needed or depended on by something else in 7.1.

Comment by Louis Williams [ 08/Sep/22 ]

I believe this ticket was filed to address the performance cost of calling restoreState() unnecessarily when updating a single document.

Comment by Josef Ahmad [ 05/Sep/22 ]

Alternatively we could batch multiple update operations together and considerably reduce the volume of saveState/restoreState. We've done something similar in the BATCHED_DELETE stage.

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