On Sun, Mar 1, 2026 at 12:59 AM Lukas Fittl <[email protected]> wrote: > > Hi, > > See attached a patch that implements a new function, > pg_buffercache_relation_stats(), which returns per-relfilenode > statistics on the number of buffers, how many are dirtied/pinned, and > their avg usage count. > > This can be used in monitoring scripts to know which relations are > kept in shared buffers, to understand performance issues better that > occur due to relations getting evicted from the cache. In our own > monitoring tool (pganalyze) we've offered a functionality like this > based on the existing pg_buffercache() function for a bit over a year > now [0], and people have found this very valuable - but it doesn't > work for larger database servers. [..] > (3 rows) > > Time: 20.991 ms [..vs] > > Time: 2.912 ms
Hi Lukas, I have glanced at the patch briefly and couldn't find any issues - patch looks solid, however I'm not sure if e.g. launching whole NBuffers scan let's say every 5mins doesn't cause latency spikes on the system? I mean introducing such function seems to invite users to use pg_buffercache and I'm wondering if such regular pattern doesn't cause issues? (this is not FUD :), just more like a question based on Your's obervation) Also have you quantified what was the breaking point of previous query? (You wrote "larger database servers", but was that like 128GB+ shared_buffers? and if so what would be the difference in terms of runtime there -- also like ~7x?) -J.
