Hi, FWIW, I think it's quite unhelpful to combine a thread to make a relatively local optimization (batched clock sweep) with huge changes to how buffer replacement works. I don't see how those things are related.
On 2026-07-22 17:52:02 +0300, Ants Aasma wrote: > I think the initial results are a promising indication that G-CLOCKs > counters are not providing much value. I am doubtful that the benchmarks in this thread actually shows anything particularly interesting wrt that. There's just not enough interesting IO in pgbench -S: - The indexes are too small compared to the table data to be interesting, even index leaf pages are unlikely to be evicted. - The fact that realistically there's at max two misses for a single query (one index leaf page and the heap page) rather substantially limits the max impact the wrong buffer replacement triggers. - I don't think the hit ratio is an all that interesting way to evaluate the cache replacement, particularly for something like pgbench -S. It really matters *which* buffers are evicted. - pgbench -S has about the same penalty for an index miss as for a heap miss (since both trigger one synchronous IO wait and since there's 1 leaf page and one heap access per query). That's not true for many other workloads. Greetings, Andres Freund
