Horton

Re: Pluggable cumulative statistics

Andres Freund <andres@anarazel.de>

View thread View on postgr.es
From: Andres Freund <andres@anarazel.de>
To: Michael Paquier <michael@paquier.xyz>
Cc: Postgres hackers <pgsql-hackers@lists.postgresql.org>
Date: 2024-07-04T21:08:25Z
Lists: pgsql-hackers 
Hi,

On 2024-07-04 14:00:47 -0700, Andres Freund wrote:
> On 2024-06-13 16:59:50 +0900, Michael Paquier wrote:
> > * Making custom stats data persistent is an interesting problem, and
> > there are a couple of approaches I've considered:
> > ** Allow custom kinds to define callbacks to read and write data from
> > a source they'd want, like their own file through a fd.  This has the
> > disadvantage to remove the benefit of c) above.
> 
> I am *strongly* against this. That'll make it much harder to do stuff like not
> resetting stats after crashes and just generally will make it harder to
> improve the stats facility further.
> 
> I think that pluggable users of the stats facility should only have control
> over how data is stored via quite generic means.


I forgot to say: In general I am highly supportive of this effort and thankful
to Michael for tackling it. The above was just about that one aspect.

Greetings,

Andres Freund

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