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