Re: Add pg_stat_autovacuum_priority - Mailing list pgsql-hackers

From Sami Imseih
Subject Re: Add pg_stat_autovacuum_priority
Date
Msg-id CAA5RZ0uL1ukKvV0Gwgok9ut_203q_E_tzBrwhDAuJCKVNwWZVw@mail.gmail.com
Whole thread
In response to Re: Add pg_stat_autovacuum_priority  (Nathan Bossart <nathandbossart@gmail.com>)
Responses Re: Add pg_stat_autovacuum_priority
List pgsql-hackers
> 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 will allow us to also avoid the GUC override as well in autovacuum.c.

--
Sami



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: s/pg_attribute_always_inline/pg_always_inline/?
Next
From: Nathan Bossart
Date:
Subject: Re: Add pg_stat_autovacuum_priority