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
