Re: Pluggable cumulative statistics - Mailing list pgsql-hackers

From Bertrand Drouvot
Subject Re: Pluggable cumulative statistics
Date
Msg-id ZoaHyR1k3X+Ks+iu@ip-10-97-1-34.eu-west-3.compute.internal
Whole thread Raw
In response to Re: Pluggable cumulative statistics  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Pluggable cumulative statistics
List pgsql-hackers
Hi,

On Wed, Jul 03, 2024 at 06:47:15PM +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,

Great!

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

That makes sense to me, and that's just a 96 bytes overhead (8 * PGSTAT_NUM_KINDS)
as compared to now.

> - PgStat_Snapshot holds an array of void* also indexed by
> PGSTAT_NUM_KINDS, pointing to the fixed stats stored in the
> snapshots.

Same, that's just a 96 bytes overhead (8 * PGSTAT_NUM_KINDS) as compared to now.

> These have a size of PgStat_KindInfo->shared_data_len, set
> up when stats are initialized at process startup, so this reflects
> everywhere.

Yeah.

> - Fixed numbered stats now set shared_size, and we use this number to
> determine the size to allocate for each fixed-numbered stats in shmem.
> - A callback is added to initialize the shared memory assigned to each
> fixed-numbered stats, consisting of LWLock initializations for the
> current types of stats.  So this initialization step is moved out of
> pgstat.c into each stats kind file.

That looks a reasonable approach to me.

> All that has been done in the rebased patch set as of 0001, which is
> kind of a nice cleanup overall because it removes all the dependencies
> to the fixed-numbered stats structures from the "main" pgstats code in
> pgstat.c and pgstat_shmem.c.

Looking at 0001:

1 ===

In the commit message:

    - Fixed numbered stats now set shared_size, so as

Is something missing in that sentence?

2 ===

@@ -425,14 +427,12 @@ typedef struct PgStat_ShmemControl
        pg_atomic_uint64 gc_request_count;

        /*
-        * Stats data for fixed-numbered objects.
+        * Stats data for fixed-numbered objects, indexed by PgStat_Kind.
+        *
+        * Each entry has a size of PgStat_KindInfo->shared_size.
         */
-       PgStatShared_Archiver archiver;
-       PgStatShared_BgWriter bgwriter;
-       PgStatShared_Checkpointer checkpointer;
-       PgStatShared_IO io;
-       PgStatShared_SLRU slru;
-       PgStatShared_Wal wal;
+       void       *fixed_data[PGSTAT_NUM_KINDS];

Can we move from PGSTAT_NUM_KINDS to the exact number of fixed stats? (add
a new define PGSTAT_NUM_FIXED_KINDS for example). That's not a big deal but we
are allocating some space for pointers that we won't use. Would need to change
the "indexing" logic though.

3 ===

Same as 2 === but for PgStat_Snapshot.

4 ===

+static void pgstat_init_snapshot(void);

what about pgstat_init_snapshot_fixed? (as it is for fixed-numbered statistics
only).

5 ===

+       /* Write various stats structs with fixed number of objects */

s/Write various stats/Write the stats/? (not coming from your patch but they
all were listed before though).

6 ===

+       for (int kind = PGSTAT_KIND_FIRST_VALID; kind <= PGSTAT_KIND_LAST; kind++)
+       {
+               char       *ptr;
+               const PgStat_KindInfo *info = pgstat_get_kind_info(kind);
+
+               if (!info->fixed_amount)
+                       continue;

Nit: Move the "ptr" declaration into an extra else? (useless to declare it
if it's not a fixed number stat)

7 ===

+               /* prepare snapshot data and write it */
+               pgstat_build_snapshot_fixed(kind);

What about changing pgstat_build_snapshot_fixed() to accept a PgStat_KindInfo
parameter (instead of the current PgStat_Kind one)? Reason is that
pgstat_get_kind_info() is already called/known in pgstat_snapshot_fixed(),
pgstat_build_snapshot() and pgstat_write_statsfile(). That would avoid
pgstat_build_snapshot_fixed() to retrieve (again) the kind_info.

8 ===

/*
 * Reads in existing statistics file into the shared stats hash.

This comment above pgstat_read_statsfile() is not correct, fixed stats
are not going to the hash (was there before your patch though).

9 ===

+pgstat_archiver_init_shmem_cb(void *stats)
+{
+       PgStatShared_Archiver *stats_shmem = (PgStatShared_Archiver *) stats;
+
+       LWLockInitialize(&stats_shmem->lock, LWTRANCHE_PGSTATS_DATA);

Nit: Almost all the pgstat_XXX_init_shmem_cb() look very similar, I wonder if we
could use a macro to avoid code duplication.

10 ===

Remark not related to this patch: I think we could get rid of the shared_data_off
for the fixed stats (by moving the "stats" part at the header of their dedicated
struct). That would mean having things like:

"
typedef struct PgStatShared_Archiver
{
    PgStat_ArchiverStats stats;
    /* lock protects ->reset_offset as well as stats->stat_reset_timestamp */
    LWLock      lock;
    uint32      changecount;
    PgStat_ArchiverStats reset_offset;
} PgStatShared_Archiver;
"

Not sure that's worth it though.

Regards,

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



pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Improving the latch handling between logical replication launcher and worker processes.
Next
From: Amit Kapila
Date:
Subject: Re: Slow catchup of 2PC (twophase) transactions on replica in LR