> On 20 Aug 2026, at 01:30, Melanie Plageman <[email protected]> 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.
