Re: Pluggable cumulative statistics
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Andres Freund <andres@anarazel.de>
Cc: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>, Postgres hackers <pgsql-hackers@lists.postgresql.org>
Date: 2024-07-04T23:44:24Z
Lists: pgsql-hackers
On Thu, Jul 04, 2024 at 01:56:52PM -0700, Andres Freund wrote:
> On 2024-07-03 18:47:15 +0900, Michael Paquier wrote:
>> - PgStat_ShmemControl holds an array of void* indexed by
>> PGSTAT_NUM_KINDS, pointing to shared memory areas allocated for each
>> fixed-numbered stats. Each entry is allocated a size corresponding to
>> PgStat_KindInfo->shared_size.
>
> I am dubious this is a good idea. The more indirection you add, the more
> expensive it gets to count stuff, the more likely it is that we end up with
> backend-local "caching" in front of the stats system.
>
> IOW, I am against making builtin stats pay the price for pluggable
> fixed-numbered stats.
Okay, noted. So, if I get that right, you would prefer an approach
where we add an extra member in the snapshot and shmem control area
dedicated only to the custom kind IDs, indexed based on the range
of the custom kind IDs, leaving the built-in fixed structures in
PgStat_ShmemControl and PgStat_Snapshot?
I was feeling a bit uncomfortable with the extra redirection for the
built-in fixed kinds, still the temptation of making that more generic
was here, so..
Having the custom fixed types point to their own array in the snapshot
and ShmemControl adds a couple more null-ness checks depending on if
you're dealing with a builtin or custom ID range. That's mostly the
path in charge of retrieving the KindInfos.
> It also substantially reduces type-safety, making it harder to refactor. Note
> that you had to add static casts in a good number of additional places.
Not sure on this one, because that's the same issue as
variable-numbered stats, no? The central dshash only knows about the
size of the shared stats entries for each kind, with an offset to the
stats data that gets copied to the snapshots. So I don't quite get
the worry here.
Separately from that, I think that read/write of the fixed-numbered
stats would gain in clarity if we update them to be closer to the
variable-numbers by storing entries with a specific character ('F' in
0001). If we keep track of the fixed-numbered structures in
PgStat_Snapshot, that means adding an extra field in PgStat_KindInfo
to point to the offset in PgStat_Snapshot for the write part. Note
that the addition of the init_shmem callback simplifies shmem init,
and it is also required for the fixed-numbered pluggable part.
--
Michael
Commits
-
injection_points: Add some fixed-numbered statistics
- f68cd847fa40 18.0 landed
-
injection_points: Add some cumulative stats for injection points
- 75534436a477 18.0 landed
-
Add helper routines to retrieve data for custom fixed-numbered pgstats
- 2eff9e678d35 18.0 landed
-
Introduce pluggable APIs for Cumulative Statistics
- 7949d9594582 18.0 landed
-
Switch PgStat_Kind from an enum to a uint32 type
- 3188a4582a8c 18.0 landed
-
Improve comment of pgstat_read_statsfile()
- 72c0b24b2ddd 18.0 landed
-
Add a new 'F' entry type for fixed-numbered stats in pgstats file
- 9e4664d950c1 18.0 landed
-
Add PgStat_KindInfo.init_shmem_cb
- 21471f18e9d9 18.0 landed
-
Use pgstat_kind_infos to write fixed shared statistics
- b68b29bc8fec 18.0 landed
-
Replace hardcoded identifiers of pgstats file by #defines
- 9fd02525793f 18.0 landed