Feedback-ID: i675e48f3:Fastmail
MIME-Version: 1.0
Date: Fri, 11 Sep 2026 10:47:56 -0400
From: "Greg Burd" <greg@burd.me>
To: "PostgreSQL Hackers" <pgsql-hackers@lists.postgresql.org>
Cc: "Jim Mlodgenski" <mlodj@amazon.com>
Message-Id: <bb80cc4b-21c1-4cab-91b3-9ee3623d6d1e@app.fastmail.com>
In-Reply-To: <4dc7c3c0-6b5e-4f5d-921f-0b1a62698b1a@app.fastmail.com>
References: <79629577-3ad8-4b1c-a469-ebc2cb4c5104@app.fastmail.com>
 <nwri4oxfusruo7yog2rewbeiegs4rhclkjukn54mcumiilak4b@6chlhxypm5sq>
 <618241c3-a1e5-4a16-be12-17a361822ee0@app.fastmail.com>
 <5bcaa70b-89c7-44b6-b197-638d10997cae@app.fastmail.com>
 <76c33898-3baa-4f7b-8b72-57dd390fcffe@app.fastmail.com>
 <9cfdf3f2-b799-485a-8b5a-5159c00ff2df@app.fastmail.com>
 <96dc1db7-58a2-41ba-ae2e-bea86fa2fb3a@app.fastmail.com>
 <q63ahnolhkswwrjnarvqp32hknr24zzdfuea62obvez3e3ix3b@gfxszrfv3wei>
 <4552df91-98bc-40e8-9189-a167daab6f0d@app.fastmail.com>
 <8bd912c8-22bb-4667-a656-3be843709be2@app.fastmail.com>
 <bokcdzldykhy7l27pumhacbrxvz2of7365iuhbrycq27d6bcyy@kpfataelljw4>
 <c596a86a-2796-4982-af85-8696d9c45a5c@app.fastmail.com>
 <4dc7c3c0-6b5e-4f5d-921f-0b1a62698b1a@app.fastmail.com>
Subject: Re: [PATCH] Batched clock sweep to reduce cross-socket atomic
 contention
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/bb80cc4b-21c1-4cab-91b3-9ee3623d6d1e%40app.fastmail.com>
Precedence: bulk

Hello,

I'm withdrawing this series, and I want to leave the reasons on the
record rather than just let the thread go quiet.

Over the last week I built Vondra's NUMA partitioning patchset
(v20260605 0001-0006 plus Wartak's 0008) and benchmarked it against both
of my patches, using Jakub Wartak's harness from the "Adding basic NUMA
awareness" thread -- his seqconcurrscans.sql and pgbenchS.sql unchanged,
scale 1000 against shared_buffers=8GB, huge_pages on, 20s runs, 5 runs
per point with the arm order rotated, datadir on a real filesystem. Two
boxes: i4i.metal (2 NUMA nodes, 128 threads) and r8i.metal-96xl (6
nodes, 384 threads). Four arms, with each arm's feature combination
verified at runtime before measuring -- partition count from
pg_buffercache_partitions, and usagecount values to confirm which
evictor was live ({1,2,3,4,5} for stock, {0,1} for HOT/COOL.)

The partitioning works, better than expected and better than my batched
approach.

Partitioning alone, versus master, on seqconcurrscans:
  2 nodes: -12% at c=1, then +12/+6/+8% at c=8/32/64
  6 nodes: -49% at c=1, then +23/+46/+47% at c=8/32/64

Then, with partitioning on in both arms, changing only the evictor from
the 0..5 clocksweep to 1-bit HOT/COOL. Ratios are per-run and paired,
which matters because the run-to-run spread here is 8-23%:

  2 nodes, seqconcurrscans   median ratio   HOT/COOL faster in
    c=1                          1.058          3/5 runs
    c=8                          1.012          4/5 runs
    c=32                         1.008          3/5 runs
    c=64                         1.030          5/5 runs
  6 nodes, seqconcurrscans
    c=1                          0.987          2/5 runs
    c=8                          1.140          4/5 runs
    c=32                         0.976          1/5 runs
    c=64                         1.036          3/5 runs

pgbenchS is flat for every arm on both boxes.

Read honestly, that is a wash. The only point I'd call real is 2 nodes
at c=64, where HOT/COOL is faster in 5 of 5 runs for about +3%;
everything else straddles 1.0 and flips sign between adjacent client
counts on the same box, which is what noise looks like. The apparent
+14% at 6 nodes / c=8 has individual ratios from 0.94 to 1.15, so I
don't believe it.

I'm dropping the batched clock sweep entirely. It solves a problem that
partitioning solves better and more generally, and I see no argument for
carrying a second mechanism for the same cache line.

Continuing to advocate for HOT/COOL, but on the NUMA thread rather than
here, and as a simplification rather than a performance patch. The case
isn't throughput, the numbers above show there isn't any once
partitioned. The case is that it replaces a 0..5 counter and its magic
constant with a single bit, it makes scan resistance a property of the
replacement algorithm instead of something the ring buffers have to bolt
on, and it removes a failure mode I measured earlier in this thread
where the 0..5 counter can spend up to five dTLB-missing visits per
victim on a large pool with huge pages off. Andres is right that I have
not shown a real-world cost for that cliff, and that remains open. But
if the buffer manager is being restructured for NUMA anyway, doing it
with one bit of replacement state rather than three seems worth arguing
for while the code is already being touched.

Thanks to Andres and Ants for the reviews on this thread. They were
blunt and they were correct, and between them they killed two of my
three ideas (the strategy removal and the ghost directory) before they
cost anyone else any time. That's the thread working.  They also pushed
for more collaboration on the Vondra thread, so here I come. :)

Marking the commitfest entry withdrawn too.

best.

-greg