Horton

Re: Pluggable cumulative statistics

Dmitry Dolgov <9erthalion6@gmail.com>

View thread View on postgr.es
From: Dmitry Dolgov <9erthalion6@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Kyotaro Horiguchi <horikyota.ntt@gmail.com>, pgsql-hackers@lists.postgresql.org
Date: 2024-07-07T10:21:26Z
Lists: pgsql-hackers 
> On Fri, Jun 21, 2024 at 01:28:11PM +0900, Michael Paquier wrote:
> On Fri, Jun 21, 2024 at 01:09:10PM +0900, Kyotaro Horiguchi wrote:
> > At Thu, 13 Jun 2024 16:59:50 +0900, Michael Paquier <michael@paquier.xyz> wrote in
> >> * The kind IDs may change across restarts, meaning that any stats data
> >> associated to a custom kind is stored with the *name* of the custom
> >> stats kind.  Depending on the discussion happening here, I'd be open
> >> to use the same concept as custom RMGRs, where custom kind IDs are
> >> "reserved", fixed in time, and tracked in the Postgres wiki.  It is
> >> cheaper to store the stats this way, as well, while managing conflicts
> >> across extensions available in the community ecosystem.
> >
> > I prefer to avoid having a central database if possible.
>
> I was thinking the same originally, but the experience with custom
> RMGRs has made me change my mind.  There are more of these than I
> thought originally:
> https://wiki.postgresql.org/wiki/CustomWALResourceManagers

From what I understand, coordinating custom RmgrIds via a wiki page was
made under the assumption that implementing a table AM with custom WAL
requires significant efforts, which limits the demand for ids. This
might not be same for custom stats -- I've got an impression it's easier
to create one, and there could be multiple kinds of stats per an
extension (one per component), right? This would mean more kind Ids to
manage and more efforts required to do that.

I agree though that it makes sense to start this way, it's just simpler.
But maybe it's worth thinking about some other solution in the long
term, taking the over-engineered prototype as a sign that more
refactoring is needed.

Commits

  1. injection_points: Add some fixed-numbered statistics

  2. injection_points: Add some cumulative stats for injection points

  3. Add helper routines to retrieve data for custom fixed-numbered pgstats

  4. Introduce pluggable APIs for Cumulative Statistics

  5. Switch PgStat_Kind from an enum to a uint32 type

  6. Improve comment of pgstat_read_statsfile()

  7. Add a new 'F' entry type for fixed-numbered stats in pgstats file

  8. Add PgStat_KindInfo.init_shmem_cb

  9. Use pgstat_kind_infos to write fixed shared statistics

  10. Replace hardcoded identifiers of pgstats file by #defines