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