[SERVER-76413] Optimize how update stage guards against the Halloween problem during multi updates Created: 21/Apr/23 Updated: 30/Jan/24 |
|
| Status: | Open |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Irina Yatsenko (Inactive) | Assignee: | Backlog - Query Execution |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Query Execution
|
| Participants: |
| Description |
|
Currently, the stage pessimistically assumes that any secondary index change during multi-update might lead to the Halloween problem, even if the changed index isn't used to scan the records (see `_updatedRecordIds` in UpdateStage). In most cases it means that if an update affects a secondary index, record ids of all updated records are temporarily stored by the stage, which might be quite a lot for some kinds of updates.
|
| Comments |
| Comment by Irina Yatsenko (Inactive) [ 09/May/23 ] |
|
Yes, though we haven't measured the potential benefits (it can be done by comparing the baseline to a hacked build that doesn't guard against the Halloween problem on workloads that have secondary indexes but don't use index scan) |