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

Generated at Thu Feb 08 06:11:02 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.