HDDS-16350. Avoid a point-get for the start-key check in RDBTable.getRangeKVs - #11169
Open
rich7420 wants to merge 1 commit into
Open
HDDS-16350. Avoid a point-get for the start-key check in RDBTable.getRangeKVs#11169rich7420 wants to merge 1 commit into
rich7420 wants to merge 1 commit into
Conversation
…RangeKVs getRangeKVs used get(startKey) == null to decide whether an absent start key returns an empty list, a full point-get whose value is discarded, right before seeking to the same key. seek() already returns the landing entry without consuming it, so compare the landing key to startKey and drop the extra point-get; the loop still starts from startKey. Behavior unchanged, covered by the new testRangeKVsStartKeyInclusiveAndAbsent and the existing testPrefixedRangeKVs. Claude-Session: https://claude.ai/code/session_01FUpCUnmy6JzHPGvwMhyGzq
chungen0126
self-requested a review
August 31, 2026 09:50
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
What changes were proposed in this pull request?
RDBTable.getRangeKVsdecided whetherstartKeyexists withget(startKey) == null,a full point-get that materializes and then discards the value
byte[], immediatelybefore
it.seek(startKey)lands the iterator on that same key.seek()already positions the iterator and returns the landing entry without consumingit (the range loop below still starts from that entry), so the existence check can reuse
the landing entry instead of a separate get:
startKeyis present iff the landing keyequals
startKey.Before:
After:
This drops one point-get per
getRangeKVscall plus the valuebyte[]it allocated onlyto discard. Behavior is unchanged: the loop still starts at the
seek()landing entry, andthe empty-result path fires on exactly the same inputs.
A JMH microbenchmark over a real RocksDB (100k keys, 512-byte values, present start key),
old (extra get) vs new (seek landing check), average time and allocation per call:
The saving is exactly one point-get: a constant ~496 B/op and ~0.5-0.6 us per call, so it is
largest as a fraction on small pages (~39% at page 1) and shrinks toward the iteration cost
as pages grow.
What is the link to the Apache Jira
https://issues.apache.org/jira/browse/HDDS-16350
How was this patch tested?
https://github.com/rich7420/ozone/actions/runs/33313659945