On Thu Jul 2, 2026 at 12:37 AM UTC, Michael Paquier wrote:
> On Wed, Jul 01, 2026 at 07:26:23PM -0500, Sami Imseih wrote:
>> Right. I also think this needs more discussion, and it should not hold
>> up everything else.
>
> Just done this way now as of 3b066de6c0a1, with more more adjustments,
> and without the sizing parts.
Thanks for committing Michael, and thanks for the reviews Bertrand and
Sami. Here is a patch that add the aforementioned entry_size column. It
is definitely needs further discussion. I am not entirely sure that
I see the value of using PgStat_KindInfo::shared_size for this column,
so I used PgStat_KindInfo::shared_data_len instead via
pgstat_get_entry_len(). My reasoning for choosing so is:
- An argument against shared_size is that I think trying to match up
pg_stat_kind_info with pg_shmem_allocations will not work well because
we will miss the additional hash table overhead
- Additionally, a few builtin stats don't even report a shared_size
(bgwriter, archiver, checkpointer, etc.)
Looking forward to see what other ideas or reasonings you all might
propose.
--
Tristan Partin
PostgreSQL Contributors Team
AWS (https://aws.amazon.com)