Skip to content

Report the rank of each entry when scanning a rank index - #4563

Merged
hatyo merged 2 commits into
mainfrom
apple/hatyo/rank-in-index-entry
Sep 10, 2026
Merged

Report the rank of each entry when scanning a rank index#4563
hatyo merged 2 commits into
mainfrom
apple/hatyo/rank-in-index-entry

Conversation

@hatyo

@hatyo hatyo commented Sep 4, 2026

Copy link
Copy Markdown
Contributor

A scan of a rank index cannot currently tell a caller what rank each entry holds. BY_RANK converts 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 what BY_VALUE yields — 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, an IndexScanBounds that accepts BY_VALUE or BY_RANK along with an includeRankAsValue option asking RankIndexMaintainer to report each entry's rank in that empty value. No new lookup was needed: the RANK record 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.

@hatyo hatyo added the enhancement New feature or request label Sep 4, 2026
@hatyo
hatyo marked this pull request as ready for review September 4, 2026 17:44
@hatyo
hatyo force-pushed the apple/hatyo/rank-in-index-entry branch 2 times, most recently from 23f9d00 to 9d2344e Compare September 4, 2026 17:56
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
hatyo force-pushed the apple/hatyo/rank-in-index-entry branch from b857c37 to 345f2db Compare September 10, 2026 10:52
@normen662

Copy link
Copy Markdown
Contributor

Please open an issue for the follow up work and add this here.

@hatyo

hatyo commented Sep 10, 2026

Copy link
Copy Markdown
Contributor Author

Please open an issue for the follow up work and add this here.

done #4608.

@hatyo
hatyo merged commit 755489b into main Sep 10, 2026
14 checks passed
@hatyo
hatyo deleted the apple/hatyo/rank-in-index-entry branch September 10, 2026 14:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants