Don't use Orca to plan SELECTs with an empty range table

[Alena0704]

Skip Orca for a SELECT with an empty range table, no sublinks and no parent
utility statement. This covers FROM-less SQL function bodies too. The rule also
applies to the bodies of SQL functions. That is why some Orca fallback messages
disappear even for queries that do have a FROM clause: the message came from
planning the function body, not the query execution itself.

For some of these queries - the ones with parameters or with SIRV functions -
Orca does not produce a plan at all and falls back, so the attempt is wasted twice over.
Skipping it makes such queries about 16x faster.

Co-Authored-By: andr-sokolov sokolov.andrey.yurevich@gmail.com

[Alena0704]

Just in case, I'll write about changes in out files of regression tests. All changes stem from one cause: trivial constant SELECTs with no range table (SELECT 1, SELECT pg_column_size(...), SELECT pg_lock_status()) now bypass ORCA and are planned by the Postgres planner.

• bfv_catalog_optimizer.out. In EXPLAIN, the two nested Result nodes and Pivotal Optimizer (GPORCA) are replaced by a single Result and Optimizer: Postgres query optimizer. Queries are simply planned by Postgres now, the plan is simpler (one node instead of two), and the result is identical.
• qp_gist_indexes2_optimizer.source. The lines DETAIL: Feature not supported: SIRV functions and the second GPORCA failed to produce a plan are gone. Previously ORCA tried to plan the constant EXPLAIN sub-query and failed twice (first on SIRV functions, then on required properties), producing a doubled fallback message. Now that trivial query never goes to ORCA, so only the single honest fallback from the real query remains.
• pgaudit.out. This is the subtlest one. The READ,SELECT,,,SELECT 1 line disappeared. The READ record is emitted by the ExecutorStart hook (commandText = sourceText), while AST_SEL is emitted by the planner hook at plan time. For SELECT 1 INTO test inside the DO block: ORCA produced a plan with two Result nodes, which PL/pgSQL does not recognize as a "simple expression", so the query ran through the executor → ExecutorStart fired → a READ line appeared. The Postgres planner produces a single Result, which PL/pgSQL recognizes as a simple expression and evaluates directly, bypassing the executor → ExecutorStart never fires → no READ line. The AST_SEL line stays because planning (and thus the planner hook) still happens in both cases.

[Alena0704]

For FROM-less SELECT queries ORCA has nothing to work with: there is no range table, nothing to distribute across segments, nothing to reorder. Its plan either matches the Postgres planner's but adds a redundant wrapping Result node and a worse cardinality estimate for set-returning functions, or it is not produced at all - ORCA fails on SIRV functions and falls back to the Postgres planner anyway. So bypassing ORCA here is not a "faster but worse plan" trade-off: the plan is strictly no worse, and better in node count and estimates, while we additionally save the entire optimization attempt - a FROM-less SELECT runs about 16x faster (0.33 ms -> 0.02 ms per query in a release build).

Query	STABLE (ORCA)	Patched (PG planner)	Speedup
SELECT 1	3,048 TPS · 0.328 ms	51,563 TPS · 0.019 ms	16.9x
SELECT 42, 'abc'::text, 1+2*3	2,492 TPS · 0.401 ms	40,079 TPS · 0.025 ms	16.1x
SELECT pg_column_size('...')	2,859 TPS · 0.350 ms	45,546 TPS · 0.022 ms	15.9x
SELECT count(*) FROM bench_t WHERE a > 10 (control)	858 TPS	849 TPS	0.99x — unchanged

[andr-sokolov]

Why does Orca build a better plan for utility statement? Can you share an example?

[Alena0704]

You are right, it is not about a better plan. The point is that such a query is not local: CREATE TABLE t AS SELECT 42 still has to distribute its result row according to the target table's policy. I reworded the comment.

[Alena0704]

I tried removing the parentStmtType condition and CI shows it is not safe: with optimizer=on the distribution policy of a CTAS table changes - matview gets Distributed by: (i) instead of Distributed randomly, legacy_hashops_ctas ends up hash-distributed on cdbhash_int4_ops, and create_table_distpol starts emitting using default RANDOM distribution. So I suggest not to add it in this PR.

[andr-sokolov]

Why is it a problem that row has to be distributed according to the target table's policy?