Re: Add pg_stat_autovacuum_priority

On Wed, Apr 08, 2026 at 04:33:00PM -0500, Sami Imseih wrote:
>> On Wed, Apr 08, 2026 at 04:40:03PM -0400, Andres Freund wrote:
>> > Note that the whole cached state does automatically get reset at the end of
>> > the transaction (AtEOXact_PgStat()->pgstat_clear_snapshot()), just like it did
>> > before the shmem stats stuff.
>>
>> I see a lot of memory used for the pgStatEntryRefHash table, too (e.g., ~16
>> MB for 100K tables). What's interesting is that I cannot reproduce similar
>> usage with views like pg_stat_all_tables. If memory was not a concern, I
>> think the "bool *may_free" idea would be fine.
>
> Instead of may_free, which is invasive, what about pgstat_fetch_entry_nocache
> which can be called by 2 new APIs pgstat_fetch_stat_tabentry_nocache() and
> pgstat_fetch_stat_tabentry_nocache_ext(). This way a caller that uses
> these will be required to pfree?

This might help avoid memory usage within a snapshot, but as Andres notes,
this gets released automatically at the end of the transaction.

For a database with 100K tables, here's what I see before calling the view:

name | used_bytes
------------------------+------------
PgStat Shared Ref Hash | 8576
PgStat Shared Ref | 2960
PgStat Pending | 4712
(3 rows)

After calling the view but before committing the transaction, I see this:

name | used_bytes
------------------------+------------
PgStat Snapshot | 4194688
PgStat Shared Ref Hash | 4194688
PgStat Shared Ref | 8048240
PgStat Pending | 3064
(4 rows)

And after committing, I see:

name | used_bytes
------------------------+------------
PgStat Shared Ref Hash | 4194688
PgStat Shared Ref | 8048240
PgStat Pending | 360
(3 rows)

--
nathan