Skip to content

Don't try to use Orca for queries that it doesn't support#279

Draft
andr-sokolov wants to merge 5 commits into
OPENGPDB_STABLEfrom
use_postgres_planner
Draft

Don't try to use Orca for queries that it doesn't support#279
andr-sokolov wants to merge 5 commits into
OPENGPDB_STABLEfrom
use_postgres_planner

Conversation

@andr-sokolov

@andr-sokolov andr-sokolov commented Oct 25, 2025

Copy link
Copy Markdown
Contributor

Don't try to use Orca for queries that it doesn't support

On translating to DXL we can find out that the query is unsupported. The better
time to make this decision is analyse stage, because in this case we can run
Postgres planner without trying to run Orca and, as a consequence, significantly
reduce planning time.
Orca doesn't support gp_dist_random, queries on master-only tables, and function
exec locations except for any. It's easy to detect on analyse stage, that
a query contains these unsupported query properties.
The number of unsupported query properties to check before translating to DXL
will be increased later.


Before the patch

postgres=# select oid from pg_class where relname='pg_class';
 oid  
------
 1259
(1 row)

Time: 9,869 ms
postgres=# 

After the patch

postgres=# select oid from pg_class where relname='pg_class';
 oid  
------
 1259
(1 row)

Time: 1,995 ms
postgres=#

Don't plan simple inserts using Orca

@leborchuk

Copy link
Copy Markdown
Contributor

+1, Also we could use PG optimizer for insert values queries

@Alena0704 Alena0704 force-pushed the use_postgres_planner branch from ab23e5e to 0f36433 Compare April 21, 2026 14:18
@Alena0704

Copy link
Copy Markdown
Contributor

I think this patch looks promising. I rebased the patch and also propose to switch off Orca to prepare query plan (last commit).

@Alena0704 Alena0704 force-pushed the use_postgres_planner branch 14 times, most recently from 4004908 to d79324e Compare June 2, 2026 22:48
@Alena0704 Alena0704 marked this pull request as ready for review June 2, 2026 22:48
@Alena0704 Alena0704 force-pushed the use_postgres_planner branch from d79324e to 8e59ffd Compare June 2, 2026 22:48
@Alena0704 Alena0704 marked this pull request as draft June 2, 2026 22:49
@Alena0704 Alena0704 force-pushed the use_postgres_planner branch from ce2eba0 to 18c9a37 Compare June 3, 2026 02:48
andr-sokolov and others added 4 commits June 3, 2026 07:55
On translating to DXL we can find out that the query is unsupported. The better
time to make this decision is analyse stage, because in this case we can run
Postgres planner without trying to run Orca and, as a consequence, significantly
reduce planning time.
Orca doesn't support gp_dist_random, queries on master-only tables, and function
exec locations except for any. It's easy to detect on analyse stage, that
a query contains these unsupported query properties.
The number of unsupported query properties to check before translating to DXL
will be increased later.
Orca doesn't support LATERAL, so a query using it is handed to Orca
only to fail during DXL translation and fall back to the Postgres
planner. As with the other unsupported properties detected at parse
analysis in the previous commit, recognize LATERAL there as well and
set usePostgresPlanner, so the Postgres planner runs directly without
the wasted Orca attempt.
The master-only detection fires on a NULL distribution policy, which
views have too, so every query over a view was needlessly pushed onto
the Postgres planner. That path keeps the view's range table entry for
permission checks, which made pgaudit emit an extra OBJECT record for
the view.

A view is expanded into its base relations before planning, so Orca
never scans the view itself. Exclude views (RELKIND_VIEW) from the check.
usePostgresPlanner was added to Query but never registered in the node
support functions, so copyObject() on a Query silently dropped it.
EXPLAIN copies the query before planning, so an EXPLAIN of a query that
set the lost it and was still handed to Orca - which then failed and
fell back, defeating the optimization.
@Alena0704 Alena0704 force-pushed the use_postgres_planner branch from 553200f to 66f9bf1 Compare June 3, 2026 04:55
@Alena0704 Alena0704 force-pushed the use_postgres_planner branch from 168b537 to dd1f6e0 Compare June 3, 2026 06:56
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.

3 participants