Re: Add pg_stat_kind_info system view
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Tristan Partin <tristan@partin.io>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>, Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Date: 2026-06-01T05:40:54Z
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
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Add system view pg_stat_kind_info
- 3b066de6c0a1 master landed
-
Introduce pluggable APIs for Cumulative Statistics
- 7949d9594582 18.0 cited