Re: Checkpointer write combining

> On 20 Aug 2026, at 01:30, Melanie Plageman <melanieplageman(at)gmail(dot)com> wrote:

Hi Melanie,

Thank you for working through the comments and for the detailed
performance analysis.

> I do have a comment on the enum about this. Should it be more
> descriptive in some way?

The enum purpose is already apparent from the name. I'd go with
something like this for BUC_MAX_ONE:

/*
* A strategy admits a buffer with usage count 1, but repeated
* strategy accesses must not make it resistant to eviction.
*/
BUC_MAX_ONE,

> I wonder whether it's worth a heuristic to avoid this.

I would very much like to avoid adding another heuristic initially. On
the other hand, the adverse workload seems less artificial than it first
sounds: a hot OLTP working set remains resident and is continuously
dirtied, while VACUUM brings the colder gaps through its ring. Writing
the hot neighbors early can then add foreground I/O only for them to be
dirtied again. Latency-sensitive OLTP is already a difficult workload
for PostgreSQL.

The opposite case is important too. When the server is under sustained
dirty-buffer pressure, writing wider contiguous batches is exactly what
should let it recover more efficiently. I do not yet see a reliable
signal that distinguishes these two cases, and the usage-count
experiment suggests that a simple filter would discard useful combining
as well.

So I do not yet have an opinion on whether the usage-count heuristic is
the right tradeoff, or whether there is a better signal. I will
think more about the adverse case, and will return to this with review of
the next group of commits.

Best regards, Andrey Borodin.