| From: | "Tristan Partin" <tristan(at)partin(dot)io> |
|---|---|
| To: | "Michael Paquier" <michael(at)paquier(dot)xyz>, "Sami Imseih" <samimseih(at)gmail(dot)com> |
| Cc: | "Bertrand Drouvot" <bertranddrouvot(dot)pg(at)gmail(dot)com>, "pgsql-hackers" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Add pg_stat_kind_info system view |
| Date: | 2026-07-06 22:52:02 |
| Message-ID: | DJRUUR0GTF9C.1MCIRTMDBBEDN@partin.io |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | 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 | Content-Type | Size |
|---|---|---|
| v1-0001-Add-entry_size-column-to-pg_stat_kind_info.patch | text/x-patch | 8.6 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Smith | 2026-07-06 23:01:00 | Re: Support EXCEPT for TABLES IN SCHEMA publications |
| Previous Message | Fujii Masao | 2026-07-06 22:43:50 | Re: Fix HAVING-to-WHERE pushdown with mismatched operator families |