[SERVER-21738] Definitively detect no-op updates Created: 02/Dec/15 Updated: 06/Dec/22 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | Write Ops |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Eric Milkie | Assignee: | Backlog - Query Execution |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Assigned Teams: |
Query Execution
|
||||||||||||
| Participants: | |||||||||||||
| Description |
|
From |
| Comments |
| Comment by Eric Milkie [ 04/Jan/19 ] |
|
I would argue it is still relevant (the code is still fragile), but now that we have removed mmapv1, in-place update support is irrelevant, so it makes completing this ticket much easier. SERVER-36405 is to improve the update code so that more no-op scenarios are detected at all, and is a lot more work. This ticket here was my proposal to simply move the logic that avoids logging no-op updates that were already detected by the current code logic. |
| Comment by Asya Kamsky [ 04/Jan/19 ] |
|
Is this still relevant and if so is it different from SERVER-36405? |
| Comment by Eric Milkie [ 10/May/16 ] |
|
Today, we detect no-op updates by hacking the onUpdate op listener, which is only active for replication. There didn't seem to be a common code path place to determine no-op-ness in the current update code; the path branches based on whether the storage engine supports in-place update. |