On Thu, 20 Aug 2026 at 12:32, David Rowley <[email protected]> wrote: > > On Thu, 20 Aug 2026 at 08:00, Alexander Lakhin <[email protected]> wrote: > > I spotted a very rare test failure (a single one in two years, at least) > > generated by basilisk: > > tidscan ... FAILED 34 ms > > ... > > diff -U3 > > /mnt/build/REL_14_STABLE/pgsql.build/../pgsql/src/test/regress/expected/tidscan.out > > /mnt/build/REL_14_STABLE/pgsql.build/src/test/regress/results/tidscan.out > > --- > > /mnt/build/REL_14_STABLE/pgsql.build/../pgsql/src/test/regress/expected/tidscan.out > > +++ > > /mnt/build/REL_14_STABLE/pgsql.build/src/test/regress/results/tidscan.out > > @@ -242,10 +242,10 @@ > > ---------------------------------------- > > Aggregate > > -> Hash Join > > - Hash Cond: (t1.ctid = t2.ctid) > > - -> Seq Scan on tenk1 t1 > > + Hash Cond: (t2.ctid = t1.ctid) > > + -> Seq Scan on tenk1 t2 > > -> Hash > > - -> Seq Scan on tenk1 t2 > > + -> Seq Scan on tenk1 t1 > > (6 rows) > > > > SELECT count(*) FROM tenk1 t1 JOIN tenk1 t2 ON t1.ctid = t2.ctid; > > I experimented, and I see the costs come out quite different if that > were changed to: > > SELECT count(*) FROM tenk1 WHERE ctid IN (SELECT DISTINCT ctid FROM tenk1);
Here's that patchified. David
0001-Attempt-to-stabilize-self-join-test-in-tidscan.sql.patch
Description: Binary data
