[SERVER-68525] Avoid updating column index unnecessarily Created: 03/Aug/22 Updated: 27/Oct/23 Resolved: 29/Dec/22 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Ian Boros | Assignee: | Dianna Hohensee (Inactive) |
| Resolution: | Works as Designed | Votes: | 0 |
| Labels: | pm2646-m5 | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Query Execution
|
| Participants: |
| Description |
|
This ticket is to investigate whether whether we perform unnecessary writes when doing updates with a column index, and to fix such cases. Case 1: The column index has a columnstoreProjection, and a field that does not fall into the projection is modified. This should not require us to write to the index at all. Case 2: Only one (or a handful) of paths are modified in an update. The unmodified paths should not have to be re-written.
|
| Comments |
| Comment by Dianna Hohensee (Inactive) [ 29/Dec/22 ] |
|
Alright, so I think, that Case 1 is also handled, by the same code. The same diff'ing code uses projection trees to create the ColumnShredders, and my understanding is that these projection trees are created by thing like columnstoreProjection settings: see here where we pass the projection into the AST creation. Therefore, the ColumnShredders are only going to look at paths of the oldObj and newObj that meet the projection AST. Therefore, fields that have not changed will not be written out to storage again – won't reach the callback function to do so. |
| Comment by Dianna Hohensee (Inactive) [ 27/Dec/22 ] |
|
Not totally positive (just found it and haven't tested anything), but I think Case 2 is already covered: this code will do nothing if a path in the old document and the new document have the same cell value, i.e. the field was unmodified. Nothing, I believe, means that the path-cell pair are not passed into a callback lambda that would write them out to storage. |