Hi Bertrand, Thanks for your review, and sorry it took me a while to get to it - other patches took more of my attention unexpectedly.
On Mon, Mar 9, 2026 at 2:15 AM Bertrand Drouvot <[email protected]> wrote: > === 1 > > +typedef struct > +{ > + RelFileNumber relfilenumber; > + Oid reltablespace; > + Oid reldatabase; > + ForkNumber forknum; > +} BufferRelStatsKey; > > What about making use of RelFileLocator (instead of 3 members relfilenumber, > reltablespace and reldatabase)? Agreed, and noted by others later too - will adjust. > + <para> > + The <function>pg_buffercache_relation_stats()</function> function returns > a > + set of rows summarizing the state of all shared buffers, aggregated by > + relation and fork number. Similar and more detailed information is > + provided by the <structname>pg_buffercache</structname> view, but > + <function>pg_buffercache_relation_stats()</function> is significantly > + cheaper. > + </para> > > I'm not 100% sure about the name of the function since the stats are "reset" > after a rewrite. What about pg_buffercache_relfilenode or > pg_buffercache_aggregated? I'll gone with "pg_buffercache_relations" for now in v2, but I could also see "pg_buffercache_relfilenodes" making sense, if we wanted to be more clear about the fact that these are physical relation files, not logical relations. Thanks, Lukas -- Lukas Fittl
