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