Re: Split index and table statistics into different types of stats

From: Melanie Plageman <melanieplageman(at)gmail(dot)com>
To: "Drouvot, Bertrand" <bertranddrouvot(dot)pg(at)gmail(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Split index and table statistics into different types of stats
Date: 2022-11-04 20:51:46
Message-ID: CAAKRu_asj8kSnukxHV764LTcUz5u-Z+iitjqesDB0yxthSm0Qw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Bertrand,

I'm glad you are working on this.

I had a few thoughts/ideas

It seems better to have all of the counts in the various stats structs
not be prefixed with n_, i_, t_

typedef struct PgStat_StatDBEntry
{
...
PgStat_Counter n_blocks_fetched;
PgStat_Counter n_blocks_hit;
PgStat_Counter n_tuples_returned;
PgStat_Counter n_tuples_fetched;
...

I've attached a patch (0002) to change this in case you are interested
in making such a change (I've attached all of my suggestions in patches
along with your original patch so that cfbot still passes).

On Wed, Nov 2, 2022 at 5:00 AM Drouvot, Bertrand
<bertranddrouvot(dot)pg(at)gmail(dot)com> wrote:
> On 11/1/22 1:30 AM, Andres Freund wrote:
> > On 2022-10-31 14:14:15 +0100, Drouvot, Bertrand wrote:
> >> @@ -240,9 +293,23 @@ pg_stat_get_blocks_fetched(PG_FUNCTION_ARGS)
> >> PG_RETURN_INT64(result);
> >> }
> >>
> >> +Datum
> >> +pg_stat_get_index_blocks_fetched(PG_FUNCTION_ARGS)
> >> +{
> >> + Oid relid = PG_GETARG_OID(0);
> >> + int64 result;
> >> + PgStat_StatIndEntry *indentry;
> >> +
> >> + if ((indentry = pgstat_fetch_stat_indentry(relid)) == NULL)
> >> + result = 0;
> >> + else
> >> + result = (int64) (indentry->blocks_fetched);
> >> +
> >> + PG_RETURN_INT64(result);
> >> +}
> >
> > We have so many copies of this by now - perhaps we first should deduplicate
> > them somehow? Even if it's just a macro or such.
> >
>
> Yeah good point, a new macro has been defined for the "int64" return
> case in V3 attached.

I looked for other opportunities to de-duplicate, but most of the functions
that were added that are identical except the return type and
PgStat_Kind are short enough that it doesn't make sense to make wrappers
or macros.

I do think it makes sense to reorder the members of the two structs
PgStat_IndexCounts and PgStat_TableCounts so that they have a common
header. I've done that in the attached patch (0003).

In the flush functions, I was also thinking it might be nice to use the
same pattern as is used in [1] and [2] to add the counts together. It
makes the lines a bit easier to read, IMO. If we remove the prefixes
from the count fields, this works for many of the fields. I've attached
a patch (0004) that does something like this, in case you wanted to go
in this direction.

Since you have made new parallel functions for indexes and tables for
many of the functions in pgstat_relation.c, perhaps it makes sense to
split it into pgstat_table.c and pgstat_index.c?

One question I had about the original code (not related to your
refactor) is why the pending stats aren't memset in the flush functions
after aggregating them into the shared stats.

- Melanie

[1] https://github.com/postgres/postgres/blob/master/src/backend/utils/activity/pgstat_checkpointer.c#L49
[2] https://github.com/postgres/postgres/blob/master/src/backend/utils/activity/pgstat_database.c#L370

Attachment Content-Type Size
v4-0003-reorder-members.patch text/x-patch 1.7 KB
v4-0001-Existing-patch-to-split-tab-and-idx.patch text/x-patch 102.3 KB
v4-0004-condense-flush-functions.patch text/x-patch 8.3 KB
v4-0002-Remove-n-i-t_-prefixes-from-stats-structs.patch text/x-patch 21.7 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2022-11-04 21:21:26 Re: remap the .text segment into huge pages at run time
Previous Message Jacob Champion 2022-11-04 20:39:47 Re: User functions for building SCRAM secrets