MIME-Version: 1.0
References: <adFiCgN22xJ7Z-oR@nathan>
 <CAA5RZ0vRP-W2wJD2OxEb-=VGj2sp5pMCqHQg9YJiuDVPhaY5jQ@mail.gmail.com>
 <adQsdvPPNviWMCXb@nathan> <5684f479-858e-4c5d-b8f5-bcf05de1f909@gmail.com>
 <3077290.1775668665@sss.pgh.pa.us> <adaWuTR7oCKodH7k@nathan>
 <3097984.1775674400@sss.pgh.pa.us> <adan_E0o69p81lIj@nathan>
 <3101163.1775676098@sss.pgh.pa.us>
 <u3akkfw3vaocviudt6f7ft4kxjc2273rh3tfhz5rfwg6jrcc2t@wurwws6wgjjz>
 <adbHYQMZ0pHQttWa@nathan>
In-Reply-To: <adbHYQMZ0pHQttWa@nathan>
From: Sami Imseih <samimseih@gmail.com>
Date: Wed, 8 Apr 2026 16:33:00 -0500
Message-ID: 
 <CAA5RZ0uL1ukKvV0Gwgok9ut_203q_E_tzBrwhDAuJCKVNwWZVw@mail.gmail.com>
Subject: Re: Add pg_stat_autovacuum_priority
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: Andres Freund <andres@anarazel.de>, Tom Lane <tgl@sss.pgh.pa.us>,
	Alexander Lakhin <exclusion@gmail.com>,
	Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>,
 Robert Treat <rob@xzilla.net>,
	satyanarlapuram@gmail.com, pgsql-hackers <pgsql-hackers@postgresql.org>,
	tndrwang@gmail.com
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
 <https://www.postgresql.org/message-id/CAA5RZ0uL1ukKvV0Gwgok9ut_203q_E_tzBrwhDAuJCKVNwWZVw%40mail.gmail.com>
Precedence: bulk

> 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