Thanks for the patch, I like the idea. > On Sat, Feb 28, 2026 at 03:58:34PM -0800, Lukas Fittl wrote: > > 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.
I see how relation footprint on the buffer cache can be useful, e.g. how many buffers per relation are used as well as how many of them are dirty. But how one can benefit from number of pinned buffers and average usage count per relation, is there a clear understanding of what to do about those numbers? > The <function>pg_buffercache_summary()</function> function returns a > single row summarizing the state of all shared buffers. > The <function>pg_buffercache_relations()</function> function returns > a set of rows summarizing the state of all shared buffers, aggregated by > relation and fork number. Maybe it was already asked before, but given those two functions (pg_buffercache_summary and pg_buffercache_relations) seems to have a very similar goal and the summary is just happening in different ways, is there a way to somehow unify them and have one function instead of two separate? It could be a unified function implementation and still two different interfaces to call, or even a single pg_buffercache_summary with an argument, specifying how to summarize. Also, would it be useful to have a numa-aware counterpart for the per-relation summary? Something like: this relation has so and so many buffers, and 50% of them are located on the node 1, while the other 50% on the node 2.
