Re: pg_buffercache: Add per-relation summary stats

Lukas Fittl <lukas@fittl.com>

From: Lukas Fittl <lukas@fittl.com>
To: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2026-03-25T06:54:18Z
Lists: pgsql-hackers
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
<bertranddrouvot.pg@gmail.com> 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



Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Modernize and optimize pg_buffercache_pages()

  2. pg_buffercache: Add pg_buffercache_os_pages

  3. Don't bother to lock bufmgr partitions in pg_buffercache.