aboutsummaryrefslogtreecommitdiff
path: root/src
diff options
context:
space:
mode:
authorDavid Rowley <drowley@postgresql.org>2024-02-16 15:01:29 +1300
committerDavid Rowley <drowley@postgresql.org>2024-02-16 15:01:29 +1300
commit1fe66680c09b6cc1ed20236c84f0913a7b786bbc (patch)
tree5a5ce19278fba544df7c6fc4c3b5d67525d47e95 /src
parentbf82f43790a675dd1b9522a7799357e61e7aa635 (diff)
downloadpostgresql-1fe66680c09b6cc1ed20236c84f0913a7b786bbc.tar.gz
postgresql-1fe66680c09b6cc1ed20236c84f0913a7b786bbc.zip
Attempt to stabilize flapping regression test
Per buildfarm animal mylodon, the plan for this test was sometimes swapping the join order for tenk1 and tenk2. Given that add_path() has no code that would cause this fluctuation when given paths with consistent costs, this indicates that the costs must be fluctuating in some runs. The only proven reason I've seen where that could happen was slight variations in pg_class.relpages for some tables. This was demonstrated to be true by f03a9ca43 and related discussion. Manually adjusting tenk2's pg_class.relpages by subtracting just 1 page does cause the plan to change for this test. Here we've not gone to the same lengths to prove that's what's going on in this case. Proving that does not seem worth the time. Let's just shrink one side of the join so the additional cost of the swapped join order is sufficiently different that if the relpages estimate is off a few pages that the planner still shouldn't swap the join order. Reported-by: Thomas Munro Author: Andy Fan, David Rowley Discussion: https://postgr.es/m/CA+hUKGLqC-NobKYfjxNM3Gexv9OJ-Fhvy9bugUcXsZjTqH7W=Q@mail.gmail.com
Diffstat (limited to 'src')
-rw-r--r--src/test/regress/expected/union.out5
-rw-r--r--src/test/regress/sql/union.sql2
2 files changed, 4 insertions, 3 deletions
diff --git a/src/test/regress/expected/union.out b/src/test/regress/expected/union.out
index 73e320bad47..882017afc9a 100644
--- a/src/test/regress/expected/union.out
+++ b/src/test/regress/expected/union.out
@@ -1438,7 +1438,7 @@ where (x = 0) or (q1 >= q2 and q1 <= q2);
-- Ensure we get a Nested Loop join between tenk1 and tenk2
explain (costs off)
select t1.unique1 from tenk1 t1
-inner join tenk2 t2 on t1.tenthous = t2.tenthous
+inner join tenk2 t2 on t1.tenthous = t2.tenthous and t2.thousand = 0
union all
(values(1)) limit 1;
QUERY PLAN
@@ -1450,8 +1450,9 @@ inner join tenk2 t2 on t1.tenthous = t2.tenthous
-> Seq Scan on tenk1 t1
-> Materialize
-> Seq Scan on tenk2 t2
+ Filter: (thousand = 0)
-> Result
-(8 rows)
+(9 rows)
-- Ensure there is no problem if cheapest_startup_path is NULL
explain (costs off)
diff --git a/src/test/regress/sql/union.sql b/src/test/regress/sql/union.sql
index 6c509ac80cb..d160db54588 100644
--- a/src/test/regress/sql/union.sql
+++ b/src/test/regress/sql/union.sql
@@ -548,7 +548,7 @@ where (x = 0) or (q1 >= q2 and q1 <= q2);
-- Ensure we get a Nested Loop join between tenk1 and tenk2
explain (costs off)
select t1.unique1 from tenk1 t1
-inner join tenk2 t2 on t1.tenthous = t2.tenthous
+inner join tenk2 t2 on t1.tenthous = t2.tenthous and t2.thousand = 0
union all
(values(1)) limit 1;