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

From: "Drouvot, Bertrand" <bertranddrouvot(dot)pg(at)gmail(dot)com>
To: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Melanie Plageman <melanieplageman(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Split index and table statistics into different types of stats
Date: 2022-12-07 10:11:20
Message-ID: e972078e-9ee2-922e-da1d-30134d483886@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

> Hi,
>
> As [1] mentioned above has been committed (83a1a1b566), please find attached V5 related to this thread making use of the new macros (namely PG_STAT_GET_RELENTRY_INT64 and PG_STAT_GET_RELENTRY_TIMESTAMPTZ).
>
> I switched from using "CppConcat" to using "##", as it looks to me it's easier to read now that we are adding another concatenation to the game (due to the table/index split).
>
> The (Tab,tab) or (Ind,ind) passed as arguments to the macros look "weird" (I don't have a better idea yet): purpose is to follow the naming convention for PgStat_StatTabEntry/PgStat_StatIndEntry and pgstat_fetch_stat_tabentry/pgstat_fetch_stat_indentry, thoughts?
>
> Looking forward to your feedback,
>

Attaching V6 (mandatory rebase due to 8018ffbf58).

While at it, I got rid of the weirdness mentioned above by creating 2 sets of macros (one for the tables and one for the indexes).

Looking forward to your feedback,

Regards,

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

Attachment Content-Type Size
v6-0001-split_tables_indexes_stats.patch text/plain 160.4 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Hamid Akhtar 2022-12-07 10:23:31 Re: Allow pageinspect's bt_page_stats function to return a set of rows instead of a single row
Previous Message Amit Langote 2022-12-07 09:47:03 Re: on placeholder entries in view rule action query's range table