Attempt to stabilize new window agg regression test

This test was recently added in 3900a02c9.  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
This commit is contained in:
David Rowley 2023-08-04 13:27:19 +12:00
parent 3fd19a9b23
commit 7516056c58
2 changed files with 7 additions and 4 deletions

View File

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

View File

@ -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