From 1c41ebf22fd43f335ae1dfbecfe6a8c6d81c5f40 Mon Sep 17 00:00:00 2001 From: David Rowley Date: Fri, 21 Aug 2026 12:25:46 +1200 Subject: [PATCH] Attempt to stabilize plan of self-join test in tidscan.sql The test that checks the expected plan for this self-join test has been known to have failed in the past due to badly timed VACUUMs causing small variations in row estimates on one of the tables, resulting in a swapped join order. Currently, failures have only been seen in v14, and seemingly due to 74388a1ac and 4496020e6 the failures have not been seen in more recent versions. Here we shrink down the number of matching rows on one side of the join to make the alternative join order's costs more expensive relative to the cheapest join order. Previously the alternative order had the same cost. We do this in all supported versions to reduce the chances of future changes reintroducing stability issues with these queries. Reported-by: Alexander Lakhin Author: David Rowley Discussion: https://postgr.es/m/f5d1f4c2-6224-4797-be17-c86e77f96c9c@gmail.com Backpatch-through: 14 --- src/test/regress/expected/tidscan.out | 22 ++++++++++++++-------- src/test/regress/sql/tidscan.sql | 16 ++++++++++++---- 2 files changed, 26 insertions(+), 12 deletions(-) diff --git a/src/test/regress/expected/tidscan.out b/src/test/regress/expected/tidscan.out index e823bc91c57..52250e09c95 100644 --- a/src/test/regress/expected/tidscan.out +++ b/src/test/regress/expected/tidscan.out @@ -237,7 +237,8 @@ ROLLBACK; -- (these plans don't use TID scans, but this still seems like an -- appropriate place for these tests) EXPLAIN (COSTS OFF) -SELECT count(*) FROM tenk1 t1 JOIN tenk1 t2 ON t1.ctid = t2.ctid; +SELECT count(*) FROM tenk1 t1 JOIN tenk1 t2 ON t1.ctid = t2.ctid +WHERE t2.ten = 0; QUERY PLAN ---------------------------------------- Aggregate @@ -246,17 +247,20 @@ SELECT count(*) FROM tenk1 t1 JOIN tenk1 t2 ON t1.ctid = t2.ctid; -> Seq Scan on tenk1 t1 -> Hash -> Seq Scan on tenk1 t2 -(6 rows) + Filter: (ten = 0) +(7 rows) -SELECT count(*) FROM tenk1 t1 JOIN tenk1 t2 ON t1.ctid = t2.ctid; +SELECT count(*) FROM tenk1 t1 JOIN tenk1 t2 ON t1.ctid = t2.ctid +WHERE t2.ten = 0; count ------- - 10000 + 1000 (1 row) SET enable_hashjoin TO off; EXPLAIN (COSTS OFF) -SELECT count(*) FROM tenk1 t1 JOIN tenk1 t2 ON t1.ctid = t2.ctid; +SELECT count(*) FROM tenk1 t1 JOIN tenk1 t2 ON t1.ctid = t2.ctid +WHERE t2.ten = 0; QUERY PLAN ----------------------------------------- Aggregate @@ -268,12 +272,14 @@ SELECT count(*) FROM tenk1 t1 JOIN tenk1 t2 ON t1.ctid = t2.ctid; -> Sort Sort Key: t2.ctid -> Seq Scan on tenk1 t2 -(9 rows) + Filter: (ten = 0) +(10 rows) -SELECT count(*) FROM tenk1 t1 JOIN tenk1 t2 ON t1.ctid = t2.ctid; +SELECT count(*) FROM tenk1 t1 JOIN tenk1 t2 ON t1.ctid = t2.ctid +WHERE t2.ten = 0; count ------- - 10000 + 1000 (1 row) RESET enable_hashjoin; diff --git a/src/test/regress/sql/tidscan.sql b/src/test/regress/sql/tidscan.sql index 1b82d5f1a53..fcea11c027a 100644 --- a/src/test/regress/sql/tidscan.sql +++ b/src/test/regress/sql/tidscan.sql @@ -86,12 +86,20 @@ ROLLBACK; -- (these plans don't use TID scans, but this still seems like an -- appropriate place for these tests) EXPLAIN (COSTS OFF) -SELECT count(*) FROM tenk1 t1 JOIN tenk1 t2 ON t1.ctid = t2.ctid; -SELECT count(*) FROM tenk1 t1 JOIN tenk1 t2 ON t1.ctid = t2.ctid; +SELECT count(*) FROM tenk1 t1 JOIN tenk1 t2 ON t1.ctid = t2.ctid +WHERE t2.ten = 0; + +SELECT count(*) FROM tenk1 t1 JOIN tenk1 t2 ON t1.ctid = t2.ctid +WHERE t2.ten = 0; + SET enable_hashjoin TO off; + EXPLAIN (COSTS OFF) -SELECT count(*) FROM tenk1 t1 JOIN tenk1 t2 ON t1.ctid = t2.ctid; -SELECT count(*) FROM tenk1 t1 JOIN tenk1 t2 ON t1.ctid = t2.ctid; +SELECT count(*) FROM tenk1 t1 JOIN tenk1 t2 ON t1.ctid = t2.ctid +WHERE t2.ten = 0; + +SELECT count(*) FROM tenk1 t1 JOIN tenk1 t2 ON t1.ctid = t2.ctid +WHERE t2.ten = 0; RESET enable_hashjoin; -- check predicate lock on CTID