Repository navigation
perf(tables): seek keyset row pages instead of scanning from the first key - #8911
Open
waleedlatif1 wants to merge 1 commit into
Open
waleedlatif1 wants to merge 1 commit into
waleedlatif1 wants to merge 1 commit into
Conversation
…t key The row drain and the export page reader advanced with `order_key IS NULL OR (order_key, id) > (anchor)`. The OR keeps the unkeyed tail reachable, but the planner cannot turn it into a range on the `(table_id, order_key, id)` index, so every page scanned the table from its first key and filtered out every row before the anchor: page cost grew with page depth. Split the seek into its two disjoint halves, the keyed rows past the anchor and the unkeyed tail, each a limited index range, and UNION ALL them under the same ORDER BY/LIMIT/OFFSET. Postgres merges the two ordered streams and reads only the rows the page can reach. Rows, order, and cursor semantics are unchanged; the inner limits cover ask + offset so a compound cursor resuming inside the unkeyed tail still lands on the same row. The db chain mock gains `unionAll`, resolving to the left chain's rows. The mock test that asserted the seek SQL text is replaced by an integration case that pages a table with keyed and unkeyed rows through both readers at several page sizes.
|
The latest updates on your projects. Learn more about Vercel for GitHub. |
Contributor
There was a problem hiding this comment.
No issues found across 5 files
Confidence score: 5/5
- Automated review surfaced no issues in the provided summaries.
- No files require special attention.
Heads up: you’ve reached your flex budget. Increase your flex budget or wait for usage to reset.
Turn on auto-fix | Re-trigger cubic
Contributor
|
This branch was previously deployed
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.
Summary
order_key IS NULL OR (order_key, id) > (anchor). The OR keeps the unkeyed tail reachable but stops the planner from seeking(table_id, order_key, id), so every page scanned from the table's first key and filtered out every row before the anchor — page cost grew with page depth.UNION ALLthem under the same ORDER BY/LIMIT/OFFSET. Inner limits coverask + offset, so a compound cursor resuming inside the unkeyed tail lands on the same row.Type of Change
Testing
service-filter-threading.test.tspasses locally; biome on changed filesChecklist
test-auditauthoring gate)