Feedback-ID: id4a34324:Fastmail
Date: Wed, 8 Apr 2026 16:40:03 -0400
From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Nathan Bossart <nathandbossart@gmail.com>,
	Alexander Lakhin <exclusion@gmail.com>, Sami Imseih <samimseih@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
Subject: Re: Add pg_stat_autovacuum_priority
Message-ID: <u3akkfw3vaocviudt6f7ft4kxjc2273rh3tfhz5rfwg6jrcc2t@wurwws6wgjjz>
References: 
 <CAA5RZ0tYzPDeXbqz9uKacRV2xjD055qrg=s3w2PEQPK8EruuSg@mail.gmail.com>
 <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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3101163.1775676098@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/u3akkfw3vaocviudt6f7ft4kxjc2273rh3tfhz5rfwg6jrcc2t%40wurwws6wgjjz>
Precedence: bulk

Hi,

On 2026-04-08 15:21:38 -0400, Tom Lane wrote:
> Hmm, yeah I suppose a caller that doesn't care about leakage could
> skip the pfree.  But are there really any of those?  The complaint
> that prompted 02502c1bc concerned databases with many many thousands
> of relations.

Most of the calls come from SQL callable functions that just return a value to
the user. For those I don't think we gain anything by doing retail pfrees, if
anything it'd hurt performance.


> I now realize that what you said upthread about caching the results
> might be a bigger problem, ie if the pgstats code does retain all
> these values then we'd have a memory bloat problem there.  Maybe
> we need a more aggressive API change that includes a way to specify
> "don't cache this result".

I can't stop myself from pointing out that the whole reason this caching stuff
exists is because you insistet that we provide an equivalent for snapshotting
semantics of the pre-shmem stats system...

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.

Greetings,

Andres Freund