public inbox for [email protected]  

help / color / mirror / Atom feed

From: Dmitry Dolgov <[email protected]>
To: Lukas Fittl <[email protected]>
Cc: Masahiko Sawada <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Cc: Paul A Jungwirth <[email protected]>
Cc: Khoa Nguyen <[email protected]>
Subject: Re: pg_buffercache: Add per-relation summary stats
Date: Fri, 27 Mar 2026 19:11:03 +0100
Message-ID: <fq7uiere55fw4dnmgnxc76metugia5qlo3msxgjh76nszsvsnm@pvkntrwv32iq> (raw)
In-Reply-To: <CAP53PkyoA2Thy8p04gL8d965DjUxX2=WcJzY6PbK-21v5fzTfA@mail.gmail.com>
References: <CAP53Pkx0=ph0vG_M20yVAoK11yGSTZP=53-rZt36OCP4hBPaDQ@mail.gmail.com>
	<CAD21AoCKz0t06-qOOm_7kgMn=Niu0yYB3R5jhOY0oVb=5AWytA@mail.gmail.com>
	<CAP53PkyoA2Thy8p04gL8d965DjUxX2=WcJzY6PbK-21v5fzTfA@mail.gmail.com>

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.

view thread (27+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: pg_buffercache: Add per-relation summary stats
  In-Reply-To: <fq7uiere55fw4dnmgnxc76metugia5qlo3msxgjh76nszsvsnm@pvkntrwv32iq>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox