Use planner for one test in "subselect"

Previously after the 9.2 merge, we had a hack that short-circuits the
execution of the join when ORCA is on. This hack stops working with the
Postgres 12 merge because the FIXME subquery gets executed on the QEs as
well rather than just on the QD. This patch simply turns ORCA off for
the query.
Co-authored-by: NJesse Zhang <sbjesse@gmail.com>
Co-authored-by: NAlexandra Wang <lewang@pivotal.io>
(cherry picked from commit 891e77d1)

src/test/regress/expected/subselect.out

@@ -626,11 +626,11 @@ select '1'::text in (select '1'::name union all select '1'::name);
 --
 -- Test case for planner bug with nested EXISTS handling
 --
-select a.thousand from tenk1 a, tenk1 b
 -- GPDB_92_MERGE_FIXME: ORCA cannot decorrelate this query, and generates
--- correct-but-slow plan that takes 45 minutes. Wedge in a hack to
--- conditionally short-circuit it only when running under ORCA
-, (SELECT name, setting FROM pg_settings WHERE (name, setting) = ('optimizer', 'off')) AS FIXME
+-- correct-but-slow plan that takes 45 minutes. Revisit this when ORCA can
+-- reorder anti-joins
+set optimizer to off;
+select a.thousand from tenk1 a, tenk1 b
 where a.thousand = b.thousand
   and exists ( select 1 from tenk1 c where b.hundred = c.hundred
                    and not exists ( select 1 from tenk1 d
@@ -639,6 +639,7 @@ where a.thousand = b.thousand
 ----------
 (0 rows)
 
+reset optimizer;
 --
 -- Check that nested sub-selects are not pulled up if they contain volatiles
 --

src/test/regress/expected/subselect_optimizer.out

@@ -644,11 +644,11 @@ select '1'::text in (select '1'::name union all select '1'::name);
 --
 -- Test case for planner bug with nested EXISTS handling
 --
-select a.thousand from tenk1 a, tenk1 b
 -- GPDB_92_MERGE_FIXME: ORCA cannot decorrelate this query, and generates
--- correct-but-slow plan that takes 45 minutes. Wedge in a hack to
--- conditionally short-circuit it only when running under ORCA
-, (SELECT name, setting FROM pg_settings WHERE (name, setting) = ('optimizer', 'off')) AS FIXME
+-- correct-but-slow plan that takes 45 minutes. Revisit this when ORCA can
+-- reorder anti-joins
+set optimizer to off;
+select a.thousand from tenk1 a, tenk1 b
 where a.thousand = b.thousand
   and exists ( select 1 from tenk1 c where b.hundred = c.hundred
                    and not exists ( select 1 from tenk1 d
@@ -657,6 +657,7 @@ where a.thousand = b.thousand
 ----------
 (0 rows)
 
+reset optimizer;
 --
 -- Check that nested sub-selects are not pulled up if they contain volatiles
 --

src/test/regress/sql/subselect.sql

@@ -390,15 +390,16 @@ select '1'::text in (select '1'::name union all select '1'::name);
 --
 -- Test case for planner bug with nested EXISTS handling
 --
-select a.thousand from tenk1 a, tenk1 b
 -- GPDB_92_MERGE_FIXME: ORCA cannot decorrelate this query, and generates
--- correct-but-slow plan that takes 45 minutes. Wedge in a hack to
--- conditionally short-circuit it only when running under ORCA
-, (SELECT name, setting FROM pg_settings WHERE (name, setting) = ('optimizer', 'off')) AS FIXME
+-- correct-but-slow plan that takes 45 minutes. Revisit this when ORCA can
+-- reorder anti-joins
+set optimizer to off;
+select a.thousand from tenk1 a, tenk1 b
 where a.thousand = b.thousand
   and exists ( select 1 from tenk1 c where b.hundred = c.hundred
                    and not exists ( select 1 from tenk1 d
                                     where a.thousand = d.thousand ) );
+reset optimizer;
 
 --
 -- Check that nested sub-selects are not pulled up if they contain volatiles