Re: Add pg_stat_autovacuum_priority

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