Lines Matching refs:be

27 product is removed, all these keys must be deleted.
37 through the to-be-deleted range, and issue a `Delete` for each key. This is
38 slow (involves read I/O) so cannot be done in any critical path. Additionally,
43 the deleted range(s). This deletes the range asynchronously, so cannot be used
55 `DeleteFilesInRange` can be used prior to compacting the deleted range as long
58 `CompactRange`, the file data would have to be rewritten several times before it
59 reaches the bottom of the LSM, where tombstones can finally be dropped.
63 of keys would be (1) simple, i.e., a single API call; (2) synchronous, i.e.,
64 when the call finishes, the keys are guaranteed to be wiped from the DB; (3) low
65 latency so it can be used in critical paths; and (4) a first-class operation
74 tombstone covering a key could be anywhere, making binary search impossible.
83 is droppable. Further, it'd be possible for keys above a range tombstone to disappear
93 tombstones to be aware of flush/compaction. An easy way to achieve this is put
128 interleave the range tombstone with point data in a way that we would be able to
144 if we implement this, the range tombstone memtable still needs to be linearly
192 root cause is range tombstones are not stored or cached in a format that can be
218  search for the key in lower levels, since we know that any keys on those levels will be
219  covered (though we do still check the current level since there may be keys written after
278  since we expect there to be relatively few range tombstones in memtables (and users can
280  after it passes a threshold). In the future, a specialized data structure can be used for storing
284 …be stored in a fragmented form. This would save time when opening SST files, and when `max_open_fi…
285 is not -1 (i.e., files may be opened several times).