Skip to content

fix: optimize regular index order-by limit#23966

Open
LeftHandCold wants to merge 4 commits intomatrixorigin:3.0-devfrom
LeftHandCold:order-by_limit
Open

fix: optimize regular index order-by limit#23966
LeftHandCold wants to merge 4 commits intomatrixorigin:3.0-devfrom
LeftHandCold:order-by_limit

Conversation

@LeftHandCold
Copy link
Copy Markdown
Contributor

What type of PR is this?

  • API-change
  • BUG
  • Improvement
  • Documentation
  • Feature
  • Test and CI
  • Code Refactoring

Which issue(s) this PR fixes:

issue #23965

What this PR does / why we need it:

Address #23965 by teaching the planner to reuse the physical order of non-unique regular secondary indexes for ORDER BY primary-key LIMIT queries when all non-PK key parts are fixed by equality filters.
Rewrite the sort anchor to the hidden serialized key, wire top-value messaging directly between sort and scan, and add focused planner tests for the optimized and non-optimized cases.

LeftHandCold and others added 2 commits March 26, 2026 18:50
Address matrixorigin#23965 by teaching the planner to reuse the physical order of non-unique regular secondary indexes for ORDER BY primary-key LIMIT queries when all non-PK key parts are fixed by equality filters.

Rewrite the sort anchor to the hidden serialized key, wire top-value messaging directly between sort and scan, and add focused planner tests for the optimized and non-optimized cases.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Add an explicit index-table layout guard for the regular secondary index ORDER BY LIMIT rewrite and extend planner coverage to validate ASC ordering as well.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Make the regular secondary index ORDER BY pk LIMIT optimization effective on the real Sort -> Index Table Scan plan shape after projection removal.

Reuse the hidden serialized index key only when the scan is a non-unique regular index scan, the ORDER BY column is the index-table PK column, and all non-PK key parts are fixed by prefix equality. Keep the scan-side ordering on the physical hidden key while preserving the original visible sort key name in EXPLAIN, and extend planner tests for both project-preserving and projection-removed paths.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
- set OrderBy on parallel local readers for ordered scans
- push block-top pruning into regular index hidden-key scan path
- trim sorted filtered block rows before feeding Top

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

kind/bug Something isn't working size/L Denotes a PR that changes [500,999] lines

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants