| From: | Ants Aasma <ants(dot)aasma(at)cybertec(dot)at> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Greg Burd <greg(at)burd(dot)me>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Tomas Vondra <tomas(at)vondra(dot)me>, Nathan Bossart <nathandbossart(at)gmail(dot)com> |
| Subject: | Re: [PATCH] Batched clock sweep to reduce cross-socket atomic contention |
| Date: | 2026-07-22 16:09:18 |
| Message-ID: | CANwKhkN2jetb37bbcroi9JJ=fPF+mgOU2JiPU7oBxutrH6BZcQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Generally agreed, but I wanted to understand one point a bit better.
On Wed, 22 Jul 2026 at 18:29, Andres Freund <andres(at)anarazel(dot)de> wrote:
> - 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.
Is that only because a single bad eviction could cause multiple
backends to wait for an I/O? To me, a high probability of multiple
accesses within one disk latency would imply that the buffer is really
hot and the eviction algorithm would have to be really terrible to
evict it. In other words, I have a hard time imagining when it would
matter in practice.
Of course with prefetching, distinguisghing prefetched misses from
synchronous misses is very much important.
Ants
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2026-07-22 16:15:35 | Re: [PATCH] Rebuild CHECK constraints after generated column SET EXPRESSION |
| Previous Message | Boris Mironov | 2026-07-22 16:04:23 | Re: Yet another PG extension to support Gzip, LZ4, Zstd functions optimized for multi-megabyte documents |