Re: Add pg_stat_kind_info system view

From: Sami Imseih <samimseih(at)gmail(dot)com>
To: Tristan Partin <tristan(at)partin(dot)io>
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 15:51:48
Message-ID: CAA5RZ0tLVRzk-ciMswAGwnkmcqMNT4deXs6Ws2b19naKzPOQAA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

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?

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.

--
Sami Imseih
Amazon Web Services (AWS)

Attachment Content-Type Size
v3-0001-Add-entry_size-column-to-pg_stat_kind_info.patch application/octet-stream 8.7 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Rui Zhao 2026-07-29 16:07:25 Re: [PATCH] Add pg_get_table_ddl() to reconstruct CREATE TABLE statements
Previous Message Álvaro Herrera 2026-07-29 15:46:40 Re: BUG: Cascading standby fails to reconnect after falling back to archive recovery