Re: Add pg_stat_kind_info system view - Mailing list pgsql-hackers

From Tristan Partin
Subject Re: Add pg_stat_kind_info system view
Date
Msg-id DJRUUR0GTF9C.1MCIRTMDBBEDN@partin.io
Whole thread
List pgsql-hackers
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)

Attachment

pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: Fix HAVING-to-WHERE pushdown with mismatched operator families
Next
From: Jeff Davis
Date:
Subject: Re: Bug in ALTER SUBSCRIPTION ... SERVER / ... CONNECTION with broken old server