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:
parent
3fd19a9b23
commit
7516056c58
|
@ -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
|
||||
--------------------------------------------------------------------------------
|
||||
-------------------------------------------------------------------
|
||||
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.
|
||||
|
|
|
@ -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
|
||||
|
|
Loading…
Reference in New Issue