swamirishi commented on PR #9553:
URL: https://github.com/apache/ozone/pull/9553#issuecomment-3863881834

   > > > ...  it completely depends on the transactions that happen together in 
the same double buffer ...
   > > 
   > > 
   > > @swamirishi , I agree. I mean that the current code does not have such 
transactions and we are not going to support such code.
   > > > ...  improves the efficiency  ...
   > > 
   > > 
   > > Let's talk about the correctness before talking about efficiency. As you 
mentioned in the description, the previously implementation (quoted below) 
indeed has a bug. So this change is very risky.
   > > > ... It also misses a case where a putKey/deleteKey can get added even 
though a deleteRange has been executed in the next batch after the following 
continuousDeleteRange batch. ...
   > 
   > It was not a bug but just inefficient. We are good as long as the order of 
operations are correct. For instance: [PUT K1, DELETE RANGE K5- K6, PUT K5 
DELETE RANGE K1- K4] is equivalent to [DELETE RANGE K5-K6, PUT K5, DELETE RANGE 
K1-K4] So corresponding to the Single Key Op PUT K1 the previous implementation 
was only looking into the very next DeleteRange operation i.e. DELETE RANGE 
K5-K6 and was performing the first set of operations if there is no 
intersection and the implementation proposed in this PR looks into optimizing 
it further and peeks into all the Delete Range that come after i.e. after PUT 
K1 there are 2 DELETE Range K5-K6 and DELETE RANGE K1-K4 and K1 has an 
intersection with DELETE RANGE K1-K4 so the operation PUT K1 can be skipped 
even if it is performed it is not an issue but just redundant. So the issue was 
never around correctness.
   
   We had done it the earlier way since the DELETE RANGE was only being used 
for Snapshot CREATE and there was going to be no intersection of DELETE RANGE 
with any of the operation beyond one transaction since SNAPSHOT CREATE splits 
the double buffer batch. This changes proposed here is for more generic use 
cases like @aryangupta1998 's PR change which is also a safe change.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to