Re: Add pg_stat_kind_info system view

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)

In response to

Browse pgsql-hackers by date

  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