Re: Add pg_stat_kind_info system view

On Fri Jul 17, 2026 at 4:58 PM UTC, Sami Imseih wrote:
> Hi,
>
>> 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
>
> As I noted earlier in this thread, my concern is that this value will be
> misused to estimate how much memory a kind uses, since it excludes overhead.
> The per-entry comment notes this, but I think the docs should also warn that
> entry_count and entry_size together do not give an accurate measure of a
> kind's total memory use, and that the DSA footprint is not shrunk when entries
> are deleted (the OS does not reclaim the freed space, so someone may be
> confused that their memory footprint stays high after deleting entries).

I add the following paragraph to the docs. I think adding a warning
makes sense.

> + <para>
> + Note that <varname>entry_count</varname> multiplied by
> + <varname>entry_size</varname> is not an accurate measure of the total memory
> + used by a statistics kind.
> + </para>

> I would also drop "serializable" from the doc wording; the column is just the
> length of a kind's statistics data payload. Not all kinds serialize their data
> to disk.
>
> So maybe:
>
> - reflects the serializable statistics payload only, and does not include
> - any shared memory overhead.
> + reflects the statistics data payload only, and does not include any
> + shared memory overhead.

Thanks, I have this change in my tree.

> So, I still think we should add shared_data_len as a column, just because it is
> one of the metadata attributes of the kind and omitting it makes this view
> incomplete, but noting why it should not be used to calculate per-kind memory
> usage is important.

Did you mean to say shared_size? pgstat_get_entry_len() returns
PgStat_KindInfo::shared_data_len, so the patch already exposes this
value.

> I think we should, in a separate view, compute how much actual memory the
> stats collector is using. Currently there is only one dsa area, but if [1]
> gets committed, and a kind could have a dedicated dsa, there will be more of
> an incentive to expose this information. This is a separate discussion.
>
> [1] https://www.postgresql.org/message-id/CAA5RZ0supQBxSkh=CWB39=j+cL3hHcLPki3tcBk0B1r4fesg_g@mail.gmail.com

I wonder if it needs to be a separate view. Anyway, a discussion for
another time.

--
Tristan Partin
PostgreSQL Contributors Team
AWS (https://aws.amazon.com)