swamirishi commented on PR #10876: URL: https://github.com/apache/ozone/pull/10876#issuecomment-5102785094
> > The first key in iterator is k00 and delete keys is k01. If pointer at deleted key is greater than iterator then iterator seeks to deleted key by adding the current deleteRange to the deleteRangeList. So the iterator is at k01 now. > > Let's say that between k00 and k01 as well as k02 and k04, there are 1 million tombstones, the RocksDB iterator is forced to iterate all these 1 million tombstone entries. This will make performance unpredictable. > > The deleteRange on [k01, k03) is not going to be worth it in that case. > > There is a RocksDB multiget https://github.com/facebook/rocksdb/wiki/MultiGet-Performance to improve performance of multiget, we can probably explore this, but I don't think the proposed algorithm above is the way to go. > > The rule of thumb for me is to never use range query (even if it's implicit like RocksDB seek) if you are planning to do point query / queries. Seek should be a relatively safe. But I just realized we cannot use deleteRange because of snapshots since snapshot diff depends on the individual tombstone entry for deletes. > > @swamirishi Anyway, we've digressed from the purpose of the original implementation, let's continue the discussion in [HDDS-14613](https://issues.apache.org/jira/browse/HDDS-14613) Yeah sure. As regards to this change I am fine with the change. I believe we should change the Compaction type to kForceOptimized. -- 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]
