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

Michael Paquier <michael@paquier.xyz>

From: Michael Paquier <michael@paquier.xyz>

To: Sami Imseih <samimseih@gmail.com>

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

Date: 2025-10-23T23:33:17Z

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.
--
Michael