Re: Add support for entry counting in pgstats

On Tue, Sep 23, 2025 at 01:39:00PM -0500, Sami Imseih wrote:
> The refcount reaches 0 when all backends release their references to the
> stat, so if something like pg_stat_statements relies on a count for
> deallocation purposes (to stay within the max), and that value only
> decrements when all references are released, then it could end up
> constantly triggering deallocation attempts. So, I am wondering if we
> actually need another value that tracks "live" entries, or those that
> have not yet been marked for drop. This means the live entries count
> is decremented as soon as the entry is set to ->dropped.

Couldn't that mean a potential bloat in terms of memory in the dshash
if we have a large cycle of objects still held around but marked to be
gone?  That sounds risky to me as it could go out of control.  The
counter tracking exactly the number of dshash entries would provide a
tighter control, and perhaps this would be OK if the actual
deallocations are grouped.  Your suggestion would not be difficult to
implement, as well, requiring an extra tweak when entries are reused,
and that's handled in a unique path.

> As a side note, maybe I am missing something here:
> In [0], should this not say ".... the entry should not be freed" instead of
> ".... the entry should not be dropped". The refcount deals with the freeing
> of the entry after all refs are released.
>
> [0]
https://github.com/postgres/postgres/blob/f2bae51dfd5b2edc460c86071c577a45a1acbfd7/src/include/utils/pgstat_internal.h#L98-L99

The sentence looks correct to me?  The refcount cannot be incremented
if an entry is marked for drop, as far as I recall.
--
Michael