]> git-server-git.apps.pok.os.sepia.ceph.com Git - rocksdb.git/commit
Fix SeekForPrev bug with Partitioned Filters and Prefix (#5907)
authorMaysam Yabandeh <myabandeh@fb.com>
Sat, 12 Oct 2019 03:28:36 +0000 (20:28 -0700)
committermyabandeh <myabandeh@fb.com>
Wed, 16 Oct 2019 17:45:17 +0000 (10:45 -0700)
commit3c0bb7fdd4006337df3e925d9f00789a15fd0756
tree4d794a156b81ad2640e31e6ff94d1c0056ed31dc
parente1eb14133a164757b3938168eb6b2762f99e6e6b
Fix SeekForPrev bug with Partitioned Filters and Prefix (#5907)

Summary:
Partition Filters make use of a top-level index to find the partition that might have the bloom hash of the key. The index is with internal key format (before format version 3). Each partition contains the i) blooms of the keys in that range ii) bloom of prefixes of keys in that range, iii) the bloom of the prefix of the last key in the previous partition.
When ::SeekForPrev(key), we first perform a prefix bloom test on the SST file. The partition however is identified using the full internal key, rather than the prefix key. The reason is to be compatible with the internal key format of the top-level index. This creates a corner case. Example:
- SST k, Partition N: P1K1, P1K2
- SST k, top-level index: P1K2
- SST k+1, Partition 1: P2K1, P3K1
- SST k+1 top-level index: P3K1
When SeekForPrev(P1K3), it should point us to P1K2. However SST k top-level index would reject P1K3 since it is out of range.
One possible fix would be to search with the prefix P1 (instead of full internal key P1K3) however the details of properly comparing prefix with full internal key might get complicated. The fix we apply in this PR is to look into the last partition anyway even if the key is out of range.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/5907

Differential Revision: D17889918

Pulled By: maysamyabandeh

fbshipit-source-id: 169fd7b3c71dbc08808eae5a8340611ebe5bdc1e
table/block_based/partitioned_filter_block.cc
table/block_based/partitioned_filter_block_test.cc