Re: PgStat_KindInfo.named_on_disk not required in shared stats

From: Andres Freund <andres(at)anarazel(dot)de>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
Subject: Re: PgStat_KindInfo.named_on_disk not required in shared stats
Date: 2024-06-07 15:30:06
Message-ID: 20240607153006.r5juqw724dbsddc7@awork3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2024-06-07 14:07:33 +0900, Michael Paquier wrote:
> While hacking on the area of pgstat_*.c, I have noticed the existence
> of named_on_disk in PgStat_KindInfo, that is here to track the fact
> that replication slots are a particular case in the PgStat_HashKey for
> the dshash table of the stats because this kind of stats requires a
> mapping between the replication slot name and the hash key.
>
> As far as I can see, this field is not required and is used nowhere,
> because the code relies on the existence of the to_serialized_name and
> from_serialized_name callbacks to do the mapping.
>
> Wouldn't it make sense to remove it? This field is defined since
> 5891c7a8ed8f that introduced the shmem stats, and has never been used
> since.

Yes, makes sense. Looks we changed direction during development a bunch of times...q

> This frees an extra bit in PgStat_KindInfo, which is going to help me
> a bit with what I'm doing with this area of the code while keeping the
> structure size the same.

Note it's just a single bit, not a full byte. So unless you need precisely 30
bits, rather than 29, I don't really see why it'd help? And i don't see a
reason to strictly keep the structure size the same.

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Srirama Kucherlapati 2024-06-07 16:30:35 RE: AIX support
Previous Message Tom Lane 2024-06-07 15:19:40 Re: XACT_EVENT for 'commit prepared'