Re: Pluggable cumulative statistics

From: Andres Freund <andres(at)anarazel(dot)de>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Pluggable cumulative statistics
Date: 2024-07-04 20:56:52
Message-ID: 20240704205652.vyj7uiuewp7w3c6y@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2024-07-03 18:47:15 +0900, Michael Paquier wrote:
> While looking at a different patch from Tristan in this area at [1], I
> still got annoyed that this patch set was not able to support the case
> of custom fixed-numbered stats, so as it is possible to plug in
> pgstats things similar to the archiver, the checkpointer, WAL, etc.
> These are plugged in shared memory, and are handled with copies in the
> stats snapshots. After a good night of sleep, I have come up with a
> good solution for that, among the following lines:

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

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.

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2024-07-04 21:00:47 Re: Pluggable cumulative statistics
Previous Message Joel Jacobson 2024-07-04 20:53:49 Re: pgsql: Add pg_get_acl() to get the ACL for a database object