Re: Add pg_stat_kind_info system view

On Tue Jul 28, 2026 at 9:39 PM UTC, Sami Imseih wrote:
> On Wed Jul 23, 2026 at 4:35 PM UTC, Tristan Partin wrote:
>> Did you mean to say shared_size? pgstat_get_entry_len() returns
>> PgStat_KindInfo::shared_data_len, so the patch already exposes this
>> value.
>
> Sorry for the confusion. I was agreeing with you, using
> pgstat_get_entry_len() is the right approach. My point was that we
> should include it (as you already do) because it's a kind attribute,
> while being clear in the docs that it cannot be used to accurately
> calculate the size of shared memory due to other overhead.

Thanks for clarifying.

> On Mon Jul 28, 2026 at 2:58 AM UTC, Michael Paquier wrote:
>> Would it help the monitoring purpose of the change if we began using
>> GetNamedDSHash() when setting up the pgstats shared hash table?
>> That would give a way to monitor the sizing of the table through
>> pg_dsm_registry_allocations, at least, tackling your concerns about
>> the imprecision of the data if we put a memory sizing field in
>> pg_stat_kind_info?
>
> I think using GetNamedDSHash() would improve things on the
> monitoring side. pg_dsm_registry_allocations would give users the
> total memory used by pgstats, and once my per-kind DSA proposal
> [1] lands, kinds with a dedicated hash would each have their own
> entry in pg_dsm_registry_allocations giving accurate per-kind
> memory accounting.
>
> pg_stat_kind_info could also expose the shmem allocation name
> as a column, so users can join back to
> pg_dsm_registry_allocations. And once [1] lands,
> pg_stat_kind_info would also expose whether a kind uses
> the shared or dedicated hash.
>
> I think to switch to GetNamedDSHash(), we would need to
> return the DSA area from GetNamedDSHash() so entry body
> allocations can use the same DSA that backs the hash. I already
> have a patch for this [2]. More thought is needed, but I can look
> into it.
>
> That said, the doc warning for entry_size is still needed.
> entry_count * entry_size cannot give you actual memory usage
> since it excludes hash overhead, entry headers, etc.
> pg_dsm_registry_allocations is where users should look for
> real memory numbers, not pg_stat_kind_info.
>
> [1] https://www.postgresql.org/message-id/CAA5RZ0supQBxSkh=CWB39=j+cL3hHcLPki3tcBk0B1r4fesg_g@mail.gmail.com
> [2] https://www.postgresql.org/message-id/flat/CAA5RZ0tKfCVqFnMZtavM42H63ha2Haf_C4mbJNWqkaW30cPW1w(at)mail(dot)gmail(dot)com

I think this is a good idea.

Attached is a v2. I wonder if we should also expose
PgStat_KindInfo::shared_size. It is another piece of metadata.

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