[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: |
|
||||||||
| 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. |