public inbox for [email protected]  

help / color / mirror / Atom feed

From: Drouvot, Bertrand <[email protected]>
To: Bharath Rupireddy <[email protected]>
Cc: Andres Freund <[email protected]>
Cc: Melanie Plageman <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: Split index and table statistics into different types of stats
Date: Tue, 22 Nov 2022 08:12:27 +0100
Message-ID: <[email protected]> (raw)
In-Reply-To: <CALj2ACV4ndwRmcRXHAhLQ2XQCUSOh343O=AF_rH-a_NeN9LdoA@mail.gmail.com>
References: <[email protected]>
	<[email protected]>
	<[email protected]>
	<CAAKRu_asj8kSnukxHV764LTcUz5u-Z+iitjqesDB0yxthSm0Qw@mail.gmail.com>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<CALj2ACV4ndwRmcRXHAhLQ2XQCUSOh343O=AF_rH-a_NeN9LdoA@mail.gmail.com>

Hi,

On 11/22/22 7:19 AM, Bharath Rupireddy wrote:
> On Mon, Nov 21, 2022 at 7:03 PM Drouvot, Bertrand
> <[email protected]> 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

view thread (17+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Split index and table statistics into different types of stats
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox