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
Iterators are commonly used with prior known bounds, and even if those bounds are specified to the iterator, there are potential optimizations RocksDB can do in a batch "fetch all key-values in this range" vs. a bounded iterator.
The assumption that the entire range will be read is potentially stronger. (There would likely be limit options on number of keys and value size, but common case would assume everything is read.)
We don't have to track complex iteration state in heap objects.
Might be more efficient to scan level by level (at least if we are allowed to return an arbitrary subset when a limit is reached, not promising the keys ordered first as an iterator would return)
The text was updated successfully, but these errors were encountered:
I'm also interested in this feature, specifically, I would like to check if there exists a key that matches a prefix without having to seek, so this part
(at least if we are allowed to return an arbitrary subset when a limit is reached, not promising the keys ordered first as an iterator would return
Iterators are commonly used with prior known bounds, and even if those bounds are specified to the iterator, there are potential optimizations RocksDB can do in a batch "fetch all key-values in this range" vs. a bounded iterator.
The text was updated successfully, but these errors were encountered: