Don't use Orca to plan FROM-less SELECT queries

[Alena0704]

Don't use Orca to plan FROM-less SELECT queries

Queries without a FROM clause - "SELECT 42", but also function calls like "SELECT pg_column_size('...')" — have nothing to distribute across segments. Orca does plan them, but its plan is no better than the Postgres planner's, so it only adds optimization overhead.

Skip Orca for such queries unless they have sublinks or parameters or come from a utility statement.

[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.