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

Hi,

On 11/22/22 7:19 AM, Bharath Rupireddy wrote:
> On Mon, Nov 21, 2022 at 7:03 PM Drouvot, Bertrand
> <bertranddrouvot(dot)pg(at)gmail(dot)com> wrote:
>>
>> On 11/21/22 12:19 AM, Andres Freund wrote:
>>>
>>> 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.
>>>
>>
>> Got it, what about creating another preparatory commit to first introduce something like:
>>
>> "
>> #define PGSTAT_DEFINE_REL_FIELD_ACCESSOR(function_name_prefix, stat_name) \
>> Datum \
>> function_name_prefix##_##stat_name(PG_FUNCTION_ARGS) \
>> { \
>> Oid relid = PG_GETARG_OID(0); \
>> int64 result; \
>> PgStat_StatTabEntry *tabentry; \
>> if ((tabentry = pgstat_fetch_stat_tabentry(relid)) == NULL) \
>> result = 0; \
>> else \
>> result = (int64) (tabentry->stat_name); \
>> PG_RETURN_INT64(result); \
>> } \
>>
>> PGSTAT_DEFINE_REL_FIELD_ACCESSOR(pg_stat_get, numscans);
>>
>> PGSTAT_DEFINE_REL_FIELD_ACCESSOR(pg_stat_get, tuples_returned);
>> .
>> .
>> .
>> "
>>
>> If that makes sense to you, I'll submit this preparatory patch.
>
> I think the macros stitching the function declarations and definitions
> is a great idea to avoid code duplicacy. We seem to be using that
> approach already - PG_FUNCTION_INFO_V1, SH_DECLARE, SH_DEFINE and its
> friends, STEMMER_MODULE and so on. +1 for first applying this
> principle for existing functions. Looking forward to the patch.
>

Thanks! Patch proposal submitted in [1].

I'll resume working on the current thread once [1] is committed.

[1]: https://www.postgresql.org/message-id/d547a9bc-76c2-f875-df74-3ad6fd9d6236%40gmail.com

Regards,

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