Report the rank of each entry when scanning a rank index - #4563
Merged
Conversation
hatyo
marked this pull request as ready for review
September 4, 2026 17:44
hatyo
force-pushed
the
apple/hatyo/rank-in-index-entry
branch
2 times, most recently
from
September 4, 2026 17:56
23f9d00 to
9d2344e
Compare
A rank index scan cannot currently tell a caller what rank each entry holds. A BY_RANK scan converts the rank range into a score range and then performs an ordinary by-value scan, so its entries are identical to those a BY_VALUE scan produces: the rank is consumed as a bound and never reported. The rank is stored in neither the entry key nor the entry value, and a rank index leaves the value empty. This adds RankScanBounds, an IndexScanBounds accepting BY_VALUE or BY_RANK together with an includeRankAsValue option that asks RankIndexMaintainer to report each entry's rank in the otherwise empty value. The rank lookup that the RANK record function already performed is reused: it needed a record only in order to evaluate the index key against it, so it is now keyed off the index key itself, which a scan already has in hand.
hatyo
force-pushed
the
apple/hatyo/rank-in-index-entry
branch
from
September 10, 2026 10:52
b857c37 to
345f2db
Compare
normen662
approved these changes
Sep 10, 2026
Contributor
|
Please open an issue for the follow up work and add this here. |
Contributor
Author
done #4608. |
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.
A scan of a rank index cannot currently tell a caller what rank each entry holds.
BY_RANKconverts the rank range into a score range and then performs an ordinary by-value scan, so its entries come back byte-for-byte identical to whatBY_VALUEyields — the rank is consumed as a bound and then discarded. It is stored in neither the entry key nor the entry value, and a rank index leaves the value empty. Anything that wants to project a rank, rather than merely filter on one, therefore has nothing to read.This adds
RankScanBounds, anIndexScanBoundsthat acceptsBY_VALUEorBY_RANKalong with anincludeRankAsValueoption askingRankIndexMaintainerto report each entry's rank in that empty value. No new lookup was needed: theRANKrecord function already computed exactly this, and it wanted a record only in order to evaluate the index key against it. Keying it off the index key instead lets a scanned entry be ranked without loading its record, and the record path reduces to producing that key first. The javadoc is explicit that the option is not free — it costs one ranked-set skip-list traversal per entry returned, so the cost grows with entries returned rather than with the range asked for.