Re: Memory leak in vac_update_relstats ?

Gregory Stark <stark@enterprisedb.com> writes:
> It seems like the impact of this is self-limiting though. The worst-case is
> going to be something which executes an extra pfree for every tuple. Or
> perhaps one for every expression in a complex query involving lots of
> expressions. Saving a few extra pfrees per tuple isn't really going to buy
> many cpu cycles.

I can't tell you how many profiles I've looked at in which palloc/pfree
were *the* dominant consumers of CPU cycles.  I'm not sure how much
could be saved this particular way, but I wouldn't dismiss it as
uninteresting.  I've actually thought about making short-term memory
contexts use a variant MemoryContext type in which pfree was a no-op and
palloc was simplified by not worrying at all about recycling space.
        regards, tom lane