Horton

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

Michael Paquier <michael@paquier.xyz>

View thread
From: Michael Paquier <michael@paquier.xyz>
To: Sami Imseih <samimseih@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-11-10T23:21:26Z
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 →

  1. Fix const correctness in pgstat data serialization callbacks

  2. test_custom_stats: Add tests with read/write of auxiliary data

  3. Allow cumulative statistics to read/write auxiliary data from/to disk

  4. test_custom_stats: Test module for custom cumulative statistics

  5. injection_points: Remove portions related to custom pgstats

  6. Rename routines for write/read of pgstats file

On Mon, Nov 10, 2025 at 01:56:23PM -0600, Sami Imseih wrote:
> I started reworking the patch, but then I realized that I don't like this
> approach of using the same callback to support serializing NameData and
> serializing extra data. In the existing "to_serialized_name" callback
> , NameData is serialized instead of the hash key, meaning that the
> "from_serialized_name" must be called before we create an entry. The
> callback translates the NameData to an objid as is the case with replication
> slots, and the key is then used to create the entry.

Thanks for looking at that.

> However, in the case of serializing extra data, we want to have already
> created the entry by the time we call the callback. For example populating
> non-key fields of an entry with a dsa_pointer after reading some serialized
> data into dsa.
>
> If we do want to support a single callback, we would need extra metadata in
> the Kind registration to let the extension tell us what the callback is used
> for and to either trigger the callback before or after entry creation. I am
> not very thrilled about doing something like this, as I see 2 very different
> use-cases here.

Ah, I see your point.  By keeping two callbacks, one to translate a
key to/from a different field (NameData currently, but it could be
something else with a different size), we would for example be able to
keep very simple the checks for duplicated entries when reading the
file.  Agreed that it would be good to keep the key lookups as stable
as we can.

So, what you are suggested is a second callback once we have called
read_chunk() and write_chunk() for a PGSTAT_FILE_ENTRY_HASH or a
PGSTAT_FILE_ENTRY_NAME and let a stats kind write in the main file
and/or one or more extra files the data they want?  I'd be fine with
that, yes, and that should work with the PGSS case in mind.
--
Michael