You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Previously, every bloom filter check in `SeekPrefixGE` required:
1. Getting the filter block from cache (atomic refcount increment)
2. Calling `MayContain` on the filter data (a very fast operation)
3. Releasing the block (atomic refcount decrement)
4. Updating hit counter (atomic increment)
For a simple bloom filter check (a few hash operations), the atomic
refcount operations represent significant overhead (especially when
there are a small number of very hot filters in the upper LSM levels).
Add a new `cache.Handle.TableFilterMayContain` method that performs
the filter check while holding the cache's read lock, without
incrementing/decrementing the refcount. The value is safe to access
while holding the read lock since eviction requires the write lock.
When the filter block is not in cache, the code falls back to the
existing `readFilterBlock` path which handles reading from disk and
populating the cache.
We no longer record these accesses as cache hits for statistics
purposes. We still record misses, and since separate statistics by
block type, we'll still know what percentage of overall misses are due
to filter blocks.
0 commit comments