diff --git a/src/test/regress/expected/subselect.out b/src/test/regress/expected/subselect.out
index b4e2c07839186ccc00052cdcfda5a13774c3c4e8..592effe750c548590b6cc80f4ee409583789c65e 100644
--- a/src/test/regress/expected/subselect.out
+++ b/src/test/regress/expected/subselect.out
@@ -689,11 +689,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
@@ -702,6 +702,7 @@ where a.thousand = b.thousand
 ----------
 (0 rows)
 
+reset optimizer;
 --
 -- Check that nested sub-selects are not pulled up if they contain volatiles
 --
diff --git a/src/test/regress/expected/subselect_optimizer.out b/src/test/regress/expected/subselect_optimizer.out
index 4b93d5636d41b3ab323d69dc4eb848795f8130dd..f710f1a1d766efda18bd779e8f88a2fd59cf8f31 100644
--- a/src/test/regress/expected/subselect_optimizer.out
+++ b/src/test/regress/expected/subselect_optimizer.out
@@ -718,11 +718,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
@@ -731,6 +731,7 @@ where a.thousand = b.thousand
 ----------
 (0 rows)
 
+reset optimizer;
 --
 -- Check that nested sub-selects are not pulled up if they contain volatiles
 --
diff --git a/src/test/regress/sql/subselect.sql b/src/test/regress/sql/subselect.sql
index e0ea097562d3ef0cba1455d9a471a0bf07740fca..dbf8e05cbff837ca2b2fd94065c6c892207bbda9 100644
--- a/src/test/regress/sql/subselect.sql
+++ b/src/test/regress/sql/subselect.sql
@@ -417,15 +417,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