Re: Add pg_stat_kind_info system view

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Tristan Partin <tristan(at)partin(dot)io>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>
Subject: Re: Add pg_stat_kind_info system view
Date: 2026-06-01 05:40:54
Message-ID: ah0bZrpJjZL2qUga@paquier.xyz
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, May 28, 2026 at 05:11:42PM +0000, Tristan Partin wrote:
> Can you share how someone might use this additional information?
>
> Not sure I understand why we would want to expose the existence of the
> callbacks to make assertions at the SQL level. I see that in
> pgstat_register_kind(), we have the following code:
>
> We could extend these invariant checks to make sure that the callbacks
> are only set when fixed_amount is true for instance. I am very much open
> to having my mind changed.

There is currently no internal mechanism to make sure that the
built-in stats kinds have a consistent setup in terms of flags and
callbacks set, so for developers we could immediately complain when
generating patches that add new stats kinds. For custom stats kinds,
loaded libraries could have more cross-checks.

Perhaps it is not worth bothering at the end, and I'd be fine to keep
the data published as minimal as you see fit. Still, fixed_amount,
write_to_file and accessed_across_databases feel like useful
additions.

If we keep shared_size, it may make sense to set it to NULL if we
don't know about it? That's the case of the built-in fixed-sized
stats kinds. We set the value for custom fixed-sized stats kinds.
--
Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro Horiguchi 2026-06-01 05:49:22 Re: Add wait events for server logging destination writes
Previous Message Henson Choi 2026-06-01 05:35:24 Re: Row pattern recognition