Peter Dillinger

I'm considering putting this on hold because * It's not totally clear to what users should do if they only provide certain kinds of keys as input and expect the...

> Also, the comparator has to accept prefixes (from prefix_extractor) Correction: only if they are provided as Seek key

Keep in mind that for us to accept this, the performance penalty would have to be minimal.

fillseq and readrandom with -readonly should suffice, with low block cache hit rate on data blocks. You can do readrandom on the same DB before-and-after to eliminate LSM structure variances....

The errors are in the output (with enough scrolling) ``` cache/cache_bench_tool.cc:809:35: warning: Use of zero-allocated memory dbs_[db_i].orig_file_number += 1; ^ cache/cache_bench_tool.cc:900:32: warning: Use of zero-allocated memory dbs_[0].orig_file_number = 0; ^...

Weird error. I thought it was talking about zero-initialized memory, but I think it means `db_count` might be zero. If you coerce or assert `db_count >= 1` that should suffice.

May have chosen a bad time to merge 🙁 (#10434 )

Also, we are concerned about the race conditions in customizable / setoptions infrastructure, e.g. #10079 and #10375. Plus we're cautious about other functional regressions like the one patched in #10378

> If we use default `ReadOptions` with `strict_capacity_limit` block cache, RocksDB would throw exception if `Insert failed due to LRU cache being full`. Correction: LRUCacheOptions My concern is that if...

> I agree that RocksDB should refactor to consider memory allocation first, however, that might take a while to do so and I don't known whether this is already in...