tkhurana

Another thing we should consider is that maxlookback on index should inherit the value of the base table. The behavior should be exactly similar to TTL where both the data...

@sanjeet006py Can you also do a perf study to rule out any performance degradation that can get introduced in the flushing path. We have some metrics at the regionserver like...

@jinggou can you resolve the merge conflicts

@jinggou I think there seems to be some formatting changes to IndexRegionObserver.java which has made the diff huge. Can we revert and just keep what's relevant.

@palashc Another test I want you to write is where there are delete markers in the beginning of the table and then you run a query like this `SELECT *...

@sanjeet006py Using nanoseconds resolution for measuring calls which themselves take less than 1ms adds considerable measurement overhead. AFAIK each call to System.nanosecond itself takes ~25- 30ns so for 2 calls...

Have you looked at the time taken by the execution of mutationPlan for upsert select on a table which has large number of rows and client side deletes which first...

> Should we just track time taken by a single `executeMutation` call and not track at further granularity? Though for executeMutation call we should track at nano seconds granularity. IMO...

@sanjeet006py Majority of times the time to create mutationPlan is so insignificant that this metric won't be useful. The only time you are interested in this metric is when the...

> Sure, that sounds good. But still I would need to track the time taken by mutation plan creation and then I would log that only when it crosses some...