Re: Add pg_stat_kind_info system view

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Sami Imseih <samimseih(at)gmail(dot)com>
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 02:58:32
Message-ID: amga2BBCz1YrV1av@paquier.xyz
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jul 17, 2026 at 11:58:40AM -0500, Sami Imseih wrote:
> 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).

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?
--
Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Previous Message Michael Paquier 2026-07-28 02:49:58 Re: NULL pointer dereference in syslogger with load_libraries() and -DEXEC_BACKEND at startup