Re: Pluggable cumulative statistics

From: Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Pluggable cumulative statistics
Date: 2024-07-08 07:22:32
Message-ID: ZouTuIwJrQQwlVJn@ip-10-97-1-34.eu-west-3.compute.internal
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On Mon, Jul 08, 2024 at 03:49:34PM +0900, Michael Paquier wrote:
> On Mon, Jul 08, 2024 at 06:39:56AM +0000, Bertrand Drouvot wrote:
> > + for (int kind = PGSTAT_KIND_FIRST_VALID; kind <= PGSTAT_KIND_LAST; kind++)
> > + {
> > + char *ptr;
> > + const PgStat_KindInfo *info = pgstat_get_kind_info(kind);
> >
> > I wonder if we could avoid going through stats that are not fixed ones. What about
> > doing something like?
> > Same would apply for the read part added in 9004abf6206e.
>
> This becomes more relevant when the custom stats are added, as this
> performs a scan across the full range of IDs supported. So this
> choice is here for consistency, and to ease the pluggability.

Gotcha.

>
> > 2 ===
> >
> > + pgstat_build_snapshot_fixed(kind);
> > + ptr = ((char *) &pgStatLocal.snapshot) + info->snapshot_ctl_off;
> > + write_chunk(fpout, ptr, info->shared_data_len);
> >
> > I think that using "shared_data_len" is confusing here (was not the case in the
> > context of 9004abf6206e). I mean it is perfectly correct but the wording "shared"
> > looks weird to me when being used here. What it really is, is the size of the
> > stats. What about renaming shared_data_len with stats_data_len?
>
> It is the stats data associated to a shared entry. I think that's OK,
> but perhaps I'm just used to it as I've been staring at this area for
> days.

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.

Except the above (which is just a Nit), 0001 LGTM.

Regards,

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message 杨伯宇 (长堂) 2024-07-08 07:22:36 回复:Re: 回复:Re: speed up pg_upgrade with large number of tables
Previous Message Nitin Jadhav 2024-07-08 07:21:16 Address the -Wuse-after-free warning in ATExecAttachPartition()