Re: [Proposal] Adding callback support for custom statistics kinds

Sami Imseih <samimseih@gmail.com>

From: Sami Imseih <samimseih@gmail.com>

To: Michael Paquier <michael@paquier.xyz>

Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>

Date: 2025-10-24T00:57:38Z

Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

Fix const correctness in pgstat data serialization callbacks
- 167cb26718e3 19 (unreleased) landed
test_custom_stats: Add tests with read/write of auxiliary data
- 481783e69f14 19 (unreleased) landed
Allow cumulative statistics to read/write auxiliary data from/to disk
- 4ba012a8ed9c 19 (unreleased) landed
test_custom_stats: Test module for custom cumulative statistics
- 31280d96a648 19 (unreleased) landed
injection_points: Remove portions related to custom pgstats
- d52c24b0f808 19 (unreleased) landed
Rename routines for write/read of pgstats file
- ed823da12891 19 (unreleased) landed

> On Thu, Oct 23, 2025 at 04:35:58PM -0500, Sami Imseih wrote:
> > Perhaps if someone wants to have separate files for each different
> > types of data,
> > we should be able to support multiple files. I think we can add an
> > option for the
> > number of files and they can then be named "pgstat.<kind>.1.stat",
> > pgstat.<kind>.2.stat",
> > etc. I rather avoid having the extension provide a set of files names.
> > So as arguments to the callback, besides the main file pointer ( as
> > you mention below),
> > we also provide the list of custom file pointers.
> >
> > what do you think?
>
> My worry here is the lack of flexibility regarding stats that could be
> split depending on the objects whose data needs to be flushed.  For
> example, stats split across multiple databases (like our good-old
> pre-v14 pgstats, but on a per-kind basis).  So I don't think that we
> can really assume that the list of file names should be fixed when we
> begin the read/write process of the main pgstats file.

I was trying to avoid an extra field in PgStat_KindInfo if possible, but
it's worthwhile to provide more flexibility to an extension. I will go
with this.

--
Sami Imseih
Amazon Web Services (AWS)