Horton

Re: Pluggable cumulative statistics

Bertrand Drouvot <bertranddrouvot.pg@gmail.com>

View thread View on postgr.es
From: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Postgres hackers <pgsql-hackers@lists.postgresql.org>
Date: 2024-07-09T05:23:03Z
Lists: pgsql-hackers

Attachments

Hi,

On Tue, Jul 09, 2024 at 10:45:05AM +0900, Michael Paquier wrote:
> On Mon, Jul 08, 2024 at 07:22:32AM +0000, Bertrand Drouvot wrote:
> > Yeah, what I meant to say is that one could think for example that's the
> > PgStatShared_Archiver size while in fact it's the PgStat_ArchiverStats size.
> > I think it's more confusing when writing the stats. Here we are manipulating
> > "snapshot" and "snapshot" offsets. It was not that confusing when reading as we
> > are manipulating "shmem" and "shared" offsets.
> > 
> > As I said, the code is fully correct, that's just the wording here that sounds
> > weird to me in the "snapshot" context.
> 
> After sleeping on it, I can see your point.  If we were to do the
> (shared_data_len -> stats_data_len) switch, could it make sense to
> rename shared_data_off to stats_data_off to have a better symmetry?
> This one is the offset of the stats data in a shmem entry, so perhaps
> shared_data_off is OK, but it feels a bit inconsistent as well.

Agree that if we were to rename one of them then the second one should be
renamed to.

I gave a second thought on it, and I think that this is the "data" part that lead
to the confusion (as too generic), what about?

shared_data_len -> shared_stats_len
shared_data_off -> shared_stats_off

That looks ok to me even in the snapshot context (shared is fine after all
because that's where the stats come from).

Attached a patch proposal doing so.

Regards,

-- 
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com

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