On Fri Jul 17, 2026 at 4:58 PM UTC, Sami Imseih wrote: > Hi, > >> I see the value of using PgStat_KindInfo::shared_size for this column, >> so I used PgStat_KindInfo::shared_data_len instead via >> pgstat_get_entry_len(). My reasoning for choosing so is: >> >> - An argument against shared_size is that I think trying to match up >> pg_stat_kind_info with pg_shmem_allocations will not work well because >> we will miss the additional hash table overhead > > 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).
I add the following paragraph to the docs. I think adding a warning makes sense. > + <para> > + Note that <varname>entry_count</varname> multiplied by > + <varname>entry_size</varname> is not an accurate measure of the total > memory > + used by a statistics kind. > + </para> > I would also drop "serializable" from the doc wording; the column is just the > length of a kind's statistics data payload. Not all kinds serialize their data > to disk. > > So maybe: > > - reflects the serializable statistics payload only, and does not > include > - any shared memory overhead. > + reflects the statistics data payload only, and does not include any > + shared memory overhead. Thanks, I have this change in my tree. > So, I still think we should add shared_data_len as a column, just because it > is > one of the metadata attributes of the kind and omitting it makes this view > incomplete, but noting why it should not be used to calculate per-kind memory > usage is important. Did you mean to say shared_size? pgstat_get_entry_len() returns PgStat_KindInfo::shared_data_len, so the patch already exposes this value. > I think we should, in a separate view, compute how much actual memory the > stats collector is using. Currently there is only one dsa area, but if [1] > gets committed, and a kind could have a dedicated dsa, there will be more of > an incentive to expose this information. This is a separate discussion. > > [1] > https://www.postgresql.org/message-id/CAA5RZ0supQBxSkh=CWB39=j+cl3hhclpki3tcbk0b1r4fes...@mail.gmail.com I wonder if it needs to be a separate view. Anyway, a discussion for another time. -- Tristan Partin PostgreSQL Contributors Team AWS (https://aws.amazon.com)
