| From: | "Tristan Partin" <tristan(at)partin(dot)io> |
|---|---|
| To: | "Sami Imseih" <samimseih(at)gmail(dot)com> |
| Cc: | "Michael Paquier" <michael(at)paquier(dot)xyz>, "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-29 16:25:56 |
| Message-ID: | DKB71NUTTD3J.3SKQTAVP9D7SK@partin.io |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed Jul 29, 2026 at 3:52 PM UTC, Sami Imseih wrote:
> Hi,
>
>> Attached is a v2. I wonder if we should also expose
>> PgStat_KindInfo::shared_size. It is another piece of metadata.
>
> I don't think we need to expose shared_size separately.
>
> The difference between shared_size and shared_data_len is
> just the internal PgStatShared_Common header, so I am not
> sure if it has any value of exposing this.
>
> entry_size (shared_data_len) already gives you the stats struct
> size, which is something meaningful to users. For example,
> an extension author adds new stats fields and entry_size
> reflects that change.
Makes sense to me.
> for v2,
>
> + Refer to <xref linkend="view-pg-dsm-registry-allocations"/> for data on
>
> I think you meant pg_shmem_allocations, which
> does show the stats shared memory block, right?
Yes, thanks for the correction.
> But that only gives the total aggregate allocation for all
> the stats kinds. Once we have a way to expose per
> stats-kind memory usage, we can add something
> at that time. wdyt?
>
> I think we can drop the warning section entirely and just
> make the column description clear enough. Something like:
>
> ```
> Size of the statistics data for each entry of this kind
> in bytes. This reflects the statistics payload only, and
> does not include shared memory overhead. It cannot be used
> to definitively calculate total memory consumption for a
> statistics kind.
> ```
>
> Attached is a v3 with this change.
Everything looks good to me!
--
Tristan Partin
PostgreSQL Contributors Team
AWS (https://aws.amazon.com)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2026-07-29 16:27:32 | Re: docs: LISTEN/NOTIFY performance considerations |
| Previous Message | Christophe Pettus | 2026-07-29 16:25:47 | Re: [PATCH v2] Don't stop a `vacuumdb --all` on a connection failure |