Changyu Bi

Is this related to #10487? It seems doing an iterator refresh with snapshot could free the pinned resources.

https://github.com/facebook/rocksdb/wiki/Memory-usage-in-RocksDB has more detail on how each RocksDB uses memory. Most of the memory can be accounted to [block cache](https://github.com/facebook/rocksdb/wiki/Block-Cache), and the cache can be shared between different RocksDB instances....

I think you'll need at least a background thread for flush and compaction. I don't know much about whether using shared resources is better, so others feel free to chime...

I see the current `Refresh()` is actually pretty heavyweight and takes similar amount of work as creating a new iterator when superversion number is changed: https://github.com/facebook/rocksdb/blob/f28d0c2020d0314e66aed240f379f2a795b6c940/db/arena_wrapped_db_iter.cc#L62-L82 So supporting iterator refresh...

Hi @rockeet, I agree this is a reasonable feature to add, and optimizing the part where superversion is not changed should be easier to implement. It's not planned yet, so...

Do you have a lot of Deletes in your app? From the perf_context, it seems that a lot of data block (`block_read_bytes`) is read due to skipping deleted entries (`internal_delete_skipped_count`)....

Hi @meilihao, I'm not an expert on compaction, so my suggestion on that is limited and others are welcomed to add more. I think tuning options that allow more compactions...

Hi @liyichao, thanks for contributing and picking up the work on delete range optimization. I added some initial thoughts and comments as I'm still going through the PR.

> @cbi42 any update to this? @liyichao I did not know you were done with the updates, I'll take a look at the PR soon.

> @cbi42 any update to this? Hi @liyichao, sorry for the late reply. We plan to go with the caching approach #10547 for now as it provides good enough (hopefully)...