Re: Pluggable cumulative statistics

> On Thu, Jul 11, 2024 at 04:42:22PM GMT, Michael Paquier wrote:
>
> 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.

I think it's fine. Although this solution feels a bit uncomfortable,
after thinking back and forth I don't see any significantly better
option. Worth noting that since the main goal is to maintain uniqueness,
fixing the kind IDs could be accomplished in more than one way, with
varying amount of control over the list of custom IDs:

* One coud say "lets keep it in wiki and let the community organize
itself somehow", and it's done.

* Another way would be to keep it in wiki, and introduce some
maintenance rules, e.g. once per release someone is going to cleanup
the list from old unmaintained extensions, correct errors if needed,
etc. Not sure if such cleanup would be needed, but it's not impossible
to image.

* Even more closed option would be to keep the kind IDs in some separate
git repository, and let committers add new records on demand,
expressed via some request form.

As far as I understand the current proposal is about the first option,
on one side of the spectrum.

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

Are you talking about this pattern?

if (pgstat_is_kind_builtin(kind))
ptr = // get something from a snapshot/shmem by offset
else
ptr = // get something from a custom_data by kind

Maybe it would be possible to hide it behind some macros or an inlinable
function with the offset and kind as arguments (and one of them will not
be used)?