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