Skip to content

ORCA: fall back to planner for ORDER BY with ordering operators (amcanorderbyop)#1652

Closed
yjhjstz wants to merge 3 commits intomainfrom
fix_orca_gist
Closed

ORCA: fall back to planner for ORDER BY with ordering operators (amcanorderbyop)#1652
yjhjstz wants to merge 3 commits intomainfrom
fix_orca_gist

Conversation

@yjhjstz
Copy link
Copy Markdown
Member

@yjhjstz yjhjstz commented Apr 1, 2026

Summary

ORCA does not support amcanorderbyop (KNN ordered index scans). Queries like ORDER BY col <-> 'value' LIMIT N on GiST indexes cannot produce ordered index scans in ORCA, resulting in inefficient Seq Scan + Sort plans instead of KNN-GiST Index Scan.

Previously, these queries accidentally got correct plans because column-level COLLATE "C" caused a blanket fallback to the PostgreSQL planner, which does support amcanorderbyop. After commit 3f4ce85 added COLLATE "C" support to ORCA, these queries lost their fallback path and regressed to slow plans.

Changes

  1. Add has_orderby_ordering_op() in walkers.c: Detects when a query's ORDER BY clause contains an operator registered as AMOP_ORDER in pg_amop (e.g., <-> for distance). When detected, ORCA falls back to the PostgreSQL planner which can generate KNN ordered index scans.

  2. Refine fallback to skip lossy distance functions: Only fall back when ALL ordering-operator expressions have at least one direct Var (column reference) argument. Expressions like circle(p,1) <-> point(0,0) wrap the column in a function call, which causes "lossy distance functions are not supported in index-only scans" errors in the planner. Such queries are left for ORCA to handle via Seq Scan + Sort.

  3. Update expected test outputs: btree_gist, pg_trgm, create_index, and gist test expected files updated to reflect the improved plans (Index Only Scan instead of Seq Scan + Sort).

Key design decisions

  • The check is precise: only ORDER BY with ordering operators triggers fallback. Other queries on the same tables (e.g., WHERE with LIKE/%, equality filters) continue to use ORCA normally.
  • The Var-argument check avoids a known planner limitation with lossy distance functions wrapped in expressions.

Test plan

  • btree_gist regression tests pass with updated expected outputs
  • pg_trgm regression tests pass with updated expected outputs
  • create_index and gist regression tests pass with updated expected outputs
  • make installcheck-world passes

yjhjstz added 3 commits April 1, 2026 07:51
…norderbyop)

ORCA does not support amcanorderbyop (KNN ordered index scans).
Queries like `ORDER BY col <-> 'value' LIMIT N` on GiST indexes
cannot produce ordered index scans in ORCA, resulting in inefficient
Seq Scan + Sort plans instead of KNN-GiST Index Scan.

Previously, these queries would accidentally get correct plans because
column-level COLLATE "C" caused a blanket fallback to the PostgreSQL
planner, which does support amcanorderbyop. After commit 3f4ce85
added COLLATE "C" support to ORCA, these queries lost their fallback
path.

Add has_orderby_ordering_op() in walkers.c to detect when a query's
ORDER BY clause contains an operator registered as AMOP_ORDER in
pg_amop (e.g., <-> for trigram/point distance). When detected, ORCA
falls back to the PostgreSQL planner which can generate KNN ordered
index scans.

The check is precise: only ORDER BY with ordering operators triggers
fallback. Other queries on the same tables (WHERE with LIKE/%%,
equality filters, etc.) continue to use ORCA normally.
Only fall back to the PostgreSQL planner when ALL ordering-operator
expressions in ORDER BY have at least one direct Var (column reference)
argument.  Expressions like "circle(p,1) <-> point(0,0)" wrap the
column in a function call, which can cause "lossy distance functions
are not supported in index-only scans" errors in the planner.  Leave
such queries for ORCA to handle via Seq Scan + Sort.
@yjhjstz yjhjstz closed this Apr 1, 2026
@yjhjstz yjhjstz deleted the fix_orca_gist branch April 1, 2026 00:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant