| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Sami Imseih <samimseih(at)gmail(dot)com> |
| Cc: | Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>, Tristan Partin <tristan(at)partin(dot)io>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Add pg_stat_kind_info system view |
| Date: | 2026-07-01 21:28:11 |
| Message-ID: | akWGa0_jZKbpzOW7@paquier.xyz |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Jul 01, 2026 at 12:21:39PM -0500, Sami Imseih wrote:
> It still does not include PgStatShared_HashEntry which is 40-bytes per entry,
> so it could add up if someone is calculating total consumption by a kind as
> number_of_entries * size_of_entry. So that should also be accounted
> for, right?
Right. I forgot about this part. HashEntry stands on top of the
PgStatShared_* structures.
> But also, because this will be used to calculate consumption, we
> should add a note in
> the documentation to differentiate between live storage usage vs the
> DSA footprint,
> which will not be shrunk when entries are deleted. Someone may be confused
> that their entries are much lower after deleting entries, but their memory
> footprint is still high because the OS does not reclaim the free'd space.
> What do you think?
Hmm. I am not completely sure which way is best here. So, I think
that I am just going to drop this field for now (entry_size as of
latest patch), and keep the rest of the patch. It's still useful to
me, and we could always add one or more memory-related field later as
we feel in this release cycle.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nathan Bossart | 2026-07-01 21:38:14 | add list of major features to the v19 release notes |
| Previous Message | Peter Smith | 2026-07-01 21:25:36 | Re: Include sequences in publications created by pg_createsubscriber |