Re: Add pg_stat_kind_info system view

From: Sami Imseih <samimseih(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Tristan Partin <tristan(at)partin(dot)io>, 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-28 21:38:54
Message-ID: CAA5RZ0umNZBMnnZbAz9rjPGOjq_JZJ2c_mQYf--8dTcZ8Bm6EA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

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

--
Sami Imseih
Amazon Web Services (AWS)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Davis 2026-07-28 22:24:52 Re: CREATE SUBSCRIPTION ... SERVER vs. pg_dump, etc.
Previous Message Greg Burd 2026-07-28 21:27:32 Re: Don't use __builtin_setjmp on aarch64 MinGW/Windows