Horton

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

Sami Imseih <samimseih@gmail.com>

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

> > Hmm.  I would like to propose something a bit more flexible,
> > refactoring and reusing some of the existing callbacks, among the
> > following lines:
> > - Rather than introducing a second callback able to do more
> > serialization work, let's expand a bit the responsibility of
> > to_serialized_name and from_serialized_name to be able to work in a
> > more extended way, renaming them to "to/from_serialized_entry", which
>
> Sure, we can go that route.

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.

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.

What do you think?

--
Sami Imseih
Amazon Web Services (AWS)