[SERVER-70984] Decouple the concepts "in-place updates" and "index updates" Created: 01/Nov/22 Updated: 29/Oct/23 Resolved: 26/Apr/23 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 6.3.0-rc0, 7.0.0-rc3 |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Arun Banala | Assignee: | Irina Yatsenko (Inactive) |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||||||
| Assigned Teams: |
Query Execution
|
||||||||||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||||||||||
| Backport Requested: |
v7.0
|
||||||||||||||||||||||||||||
| Sprint: | QE 2023-02-06, QE 2023-02-20, QE 2023-03-06, QE 2023-03-20, QE 2023-04-03, QE 2023-04-17, QE 2023-05-01 | ||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||
| Description |
|
The current code has this odd logic to disable "in-place updates" if any of the indexes are being updated as part of the update operation. After After a bunch of discussions, we've realized that the "in-place updates" is a concept of MMAPv1 storage engine, which had true in-place updates, where the old object and new object pointed to the same memory. So if the update affected secondary indexes those would still need to be updated because the index key isn't referring the same memory as oldObj / newObj. It should be safe to remove all logic that has in-place updates and index updates coupling. As a consequence of removing the above mentioned code block, we'll be able to do a nice cleanup of the computation logic of indexesAffected flag. |
| Comments |
| Comment by Githook User [ 30/May/23 ] |
|
Author: {'name': 'Irina Yatsenko', 'email': 'irina.yatsenko@mongodb.com', 'username': 'IrinaYatsenko'}Message: |
| Comment by Githook User [ 30/May/23 ] |
|
Author: {'name': 'Irina Yatsenko', 'email': 'irina.yatsenko@mongodb.com', 'username': 'IrinaYatsenko'}Message: |
| Comment by Githook User [ 26/Apr/23 ] |
|
Author: {'name': 'Irina Yatsenko', 'email': 'irina.yatsenko@mongodb.com', 'username': 'IrinaYatsenko'}Message: |
| Comment by Githook User [ 21/Apr/23 ] |
|
Author: {'name': 'Irina Yatsenko', 'email': 'irina.yatsenko@mongodb.com', 'username': 'IrinaYatsenko'}Message: |
| Comment by Irina Yatsenko (Inactive) [ 17/Apr/23 ] |
|
I'm not sure about the linked BF. I wouldn't expect asking about whether indexes might be affected twice to drive the latency up that much. On the other hand, there was churn in the area so it's conceivable that the changes above or the remaining work for this ticket would improve perf. I'm looking at it right now. |
| Comment by Zixuan Zhuang [ 17/Apr/23 ] |
|
irina.yatsenko@mongodb.com I see. I found this ticket because it is linked to a hot BF BF-27578, do those PRs solve the BF or we still need more steps? |
| Comment by Irina Yatsenko (Inactive) [ 17/Apr/23 ] |
|
The linked PRs are merged but they represent partial steps towards the ultimate goal of the ticket. |
| Comment by Zixuan Zhuang [ 17/Apr/23 ] |
|
irina.yatsenko@mongodb.com The linked PRs are all merged, can we close this ticket? |
| Comment by Githook User [ 08/Feb/23 ] |
|
Author: {'name': 'Irina Yatsenko', 'email': 'irina.yatsenko@mongodb.com', 'username': 'IrinaYatsenko'}Message: |
| Comment by Githook User [ 02/Feb/23 ] |
|
Author: {'name': 'Irina Yatsenko', 'email': 'irina.yatsenko@mongodb.com', 'username': 'IrinaYatsenko'}Message: |