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: