Re: Pluggable cumulative statistics

On Wed, Jul 10, 2024 at 09:00:31AM +0000, Bertrand Drouvot wrote:
> On Wed, Jul 10, 2024 at 08:28:56AM +0000, Bertrand Drouvot wrote:
>> v5-0001 LGTM.

Thanks. I've applied this refactoring piece.

> /*
> * We found an existing statistics file. Read it and put all the hash
> * table entries into place.
> */

Indeed. Reworded that slightly and applied it as well.

So we are down to the remaining parts of the patch, and this is going
to need a consensus about a few things because this impacts the
developer experience when implementing one's own custom stats:
- Are folks OK with the point of fixing the kind IDs in time like
RMGRs with a control in the wiki? Or should a more artistic approach
be used like what I am mentioning at the bottom of [1]. The patch
allows a range of IDs to be used, to make the access to the stats
faster even if some area of memory may not be used.
- The fixed-numbered custom stats kinds are stored in an array in
PgStat_Snapshot and PgStat_ShmemControl, so as we have something
consistent with the built-in kinds. This makes the tracking of the
validity of the data in the snapshots split into parts of the
structure for builtin and custom kinds. Perhaps there are better
ideas than that? The built-in fixed-numbered kinds have no
redirection.
- The handling of both built-in and custom kinds touches some areas of
pgstat.c and pgstat_shmem.c, which is the minimal I could come up
with.

Attached is a rebased patch set with the remaining pieces.

[1]: https://www.postgresql.org/message-id/ZoshTO9K7O7Z1wrX%40paquier.xyz
--
Michael