Add LowerBound to allow range scans #24
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR adds a
SeekLowerBound
method toIterator
which allows for range scans of the radix tree. Lower bound seeks the iterator to the first key that is greater than or equal to some search key. The iterator can then be used to iterate in order over the rest of the values. A caller can simply stop when the result is "to high" to bound the range at the upper end.For example, assume radix trees are sorted fixed length representation of an integer such as "00001" (these might represent timestamps or some other sparse, monotonically increasing value).
Limitations
There is no
*Watch
variant of this seek method because in general there is no single node that is guaranteed to be updated when the lower bound changes (other than the root). Note that even if such an algorithm could be found, it likely isn't what callers want when using this for range scans because it only tells them that the start of the range changed not about any changes in the middle or end of the range.Callers that need to be notified of changes must arrange for that separately, for example by watching another key that is always updated when events they care about occur, or watching the root node and comparing changes to the lower bound.
Testing
This was surprisingly subtle to get right with prefix compression. An initial implementation passed a range of example-based table tests but I wasn't confident still so wrote a Fuzz test using
testing/quick
which caught several fundamental flaws.This implementation now passes table tests, including some based on simplified cases caught by fuzz testing, as well as property-based fuzz testing with random keys and comparison to a simple/naive implementation with a sorted list.