Re: Add pg_stat_kind_info system view

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+cL3hHcLPki3tcBk0B1r4fesg_g@mail.gmail.com

--
Sami