Attempt to stabilize new window agg regression test

david-rowley · david-rowley · commit 7516056c584e · 2023-08-04T13:27:19.000+12:00
This test was recently added in 3900a02. It appears to be unstable in regards to the join order presumably due to the relations at either side of the join being equal in side. Here we add a qual to make one of them smaller so the planner is more likely to choose to hash the smaller of the two. Reported-by: Nathan Bossart, Tom Lane Discussion: https://www.postgr.es/m/20230803235403.GC1238296@nathanxps13
diff --git a/src/test/regress/expected/window.out b/src/test/regress/expected/window.out
@@ -4834,17 +4834,19 @@ LIMIT 1;
 EXPLAIN (COSTS OFF)
 SELECT COUNT(*) OVER ()
 FROM tenk1 t1 INNER JOIN tenk1 t2 ON t1.unique1 = t2.tenthous
+WHERE t2.two = 1
 LIMIT 1;
-                                   QUERY PLAN                                   
---------------------------------------------------------------------------------
+                            QUERY PLAN                             
+-------------------------------------------------------------------
  Limit
    ->  WindowAgg
          ->  Hash Join
                Hash Cond: (t1.unique1 = t2.tenthous)
                ->  Index Only Scan using tenk1_unique1 on tenk1 t1
                ->  Hash
-                     ->  Index Only Scan using tenk1_thous_tenthous on tenk1 t2
-(7 rows)
+                     ->  Seq Scan on tenk1 t2
+                           Filter: (two = 1)
+(8 rows)
 
 -- Ensure we get a cheap total plan.  This time use UNBOUNDED FOLLOWING, which
 -- needs to read all join rows to output the first WindowAgg row.
diff --git a/src/test/regress/sql/window.sql b/src/test/regress/sql/window.sql
@@ -1734,6 +1734,7 @@ LIMIT 1;
 EXPLAIN (COSTS OFF)
 SELECT COUNT(*) OVER ()
 FROM tenk1 t1 INNER JOIN tenk1 t2 ON t1.unique1 = t2.tenthous
+WHERE t2.two = 1
 LIMIT 1;
 
 -- Ensure we get a cheap total plan.  This time use UNBOUNDED FOLLOWING, which
