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
