Re: [PATCH] Batched clock sweep to reduce cross-socket atomic contention - Mailing list pgsql-hackers

On Tue, 14 Jul 2026 at 20:53, Greg Burd <greg@burd.me> wrote:
> The buffer cache ring strategy didn't only bound cache pollution, it also
> deferred writeback. A backend running a big COPY, bulk UPDATE or VACUUM
> reused a small ring and, via StrategyRejectBuffer, pushed dirty victims back
> for the bgwriter and checkpointer to write instead of writing (and
> WAL-flushing) them inline on its own allocation path.  Pull the rings (as in
> 0003) and, done naively, that deferral goes too.
...
> One caveat up front: (2) is INSERT...SELECT, not the COPY command.  It hits
> the same relation-extend + WAL-logged-write path BAS_BULKWRITE served, which
> is what I wanted to stress, but if that distinction matters to anyone's
> conclusion I'll re-run with COPY FROM.

That is not quite right. First of all, bulk update and insert..select
do not use a bulkwrite strategy. COPY and CREATE TABLE AS do.
Secondly, you have it the wrong way around, the idea of bulkwrite is
to have the backend itself handle the writes. It reduces cache
pollution, but it also forces the bulk writer to handle the work it
created, so unrelated backends don't get slowed down doing the work
that the bulk writer created. StrategyRejectBuffer is only for bulk
reads. A seq scan based update would be using BAS_BULKREAD, but as you
noted, after 256kB it will fall back to normal allocation.

If we are to get rid of the ring buffer then I think we need some
other way to apply backpressure on bulk writers. Just making the
bgwriter more aggressive doesn't help when writing out the modified is
the bottleneck. It will just fall behind until every allocation is
forced to do a flush.

So the differences observed in the bulk insert and update workloads
isn't explained by getting rid of the ring buffers. It must be related
to differing eviction patterns. I think that should be easy to
demonstrate by also benchmarking only the first two patches.

> This idea started with the question of, "I wonder if we really need a 5
> count on each buffer in the clock-sweep eviction path or if that is simply
> overhead and carries no signal at all for eviction or information useful to
> the bgwriter?"  FWIW, I feel that the COOL/HOT clock is simplier and that
> tests show it is better than the 0..5 clock.  I'm not thrilled by *any*
> regression, especially not one that induces more WAL traffic, so I'm open to
> thoughts on this.

I think the initial results are a promising indication that G-CLOCKs
counters are not providing much value. But to have confidence in not
regressing we need to cover a much wider gamut of access patterns.
Another design dimension is the pure miss rate, which is relevant for
direct I/O based systems and miss rate when combined with kernel page
cache. Seems to me that a more systematic way to generate different
access pattern mixes is needed to identify potential regressions.

Btw. on the surface the algorithm looks like CLOCK-Pro [1]. The
literature might offer some interesting tuning tips.

Regards,
Ants

[1] https://www.usenix.org/legacy/event/usenix05/tech/general/full_papers/jiang/jiang.pdf