Don't use Orca to plan trivial constant queries

[Alena0704]

Don't use Orca to plan trivial constant queries

Queries such as "SELECT 42" have no range table and nothing to distribute across segments. Sending them to Orca brings no benefit and only adds optimization overhead before falling back to the Postgres planner anyway.

[andr-sokolov]

I think we should somehow change this condition to don't affect this test

 select aggfns(a,b,c)
   from (values (1,3,'foo'),(0,null,null),(2,2,'bar'),(3,1,'baz')) v(a,b,c);
-INFO:  GPORCA failed to produce a plan, falling back to planner
-DETAIL:  Feature not supported: ROW EXPRESSION
-CONTEXT:  SQL function "aggfns_trans" during startup

[Alena0704]

I had to update the expected .out files because we now never invoke Orca for trivial constant queries, so there is nothing to fail and the notice is gone.

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

[andr-sokolov]

This query is not a trivial constant query, but Orca doesn't plan it now. Fix please the PR description