From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | "Drouvot, Bertrand" <bertranddrouvot(dot)pg(at)gmail(dot)com> |
Cc: | 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-11-20 23:19:06 |
Message-ID: | 20221120231906.aayfz5jpipqd6hoz@awork3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2022-11-18 12:18:38 +0100, Drouvot, Bertrand wrote:
> On 11/16/22 9:12 PM, Andres Freund wrote:
> > This still leaves a fair bit of boilerplate. ISTM that the function body
> > really should just be a single line.
> >
> > Might even be worth defining the whole function via a macro. Perhaps something like
> >
> > PGSTAT_DEFINE_REL_FIELD_ACCESSOR(PGSTAT_KIND_INDEX, pg_stat_get_index, numscans);
>
> Thanks for the feedback!
>
> Right, what about something like the following?
>
> "
> #define PGSTAT_FETCH_STAT_ENTRY(pgstat_entry_kind, pgstat_fetch_stat_function, relid, stat_name) \
> do { \
> pgstat_entry_kind *entry = pgstat_fetch_stat_function(relid); \
> PG_RETURN_INT64(entry == NULL ? 0 : (int64) (entry->stat_name)); \
> } while (0)
>
> Datum
> pg_stat_get_index_numscans(PG_FUNCTION_ARGS)
> {
> PGSTAT_FETCH_STAT_ENTRY(PgStat_StatIndEntry, pgstat_fetch_stat_indentry, PG_GETARG_OID(0), numscans);
> }
> "
That's better, but still seems like quite a bit of repetition, given the
number of accessors. I think I like my idea of a macro defining the whole
function a bit better.
I'd define a "base" macro and then a version that's specific to tables and
indexes each, so that the pieces related to that don't have to be repeated as
often.
> > This should probably be done in a preparatory commit.
>
> Proposal submitted in [1].
Now merged.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2022-11-20 23:57:20 | Re: Polyphase merge is obsolete |
Previous Message | Ted Yu | 2022-11-20 23:15:34 | Re: Getting rid of SQLValueFunction |