Re: Memory leak in vac_update_relstats ? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Memory leak in vac_update_relstats ?
Date
Msg-id 14989.1184963041@sss.pgh.pa.us
Whole thread Raw
In response to Re: Memory leak in vac_update_relstats ?  (Gregory Stark <stark@enterprisedb.com>)
Responses Re: Memory leak in vac_update_relstats ?  (Andrew Dunstan <andrew@dunslane.net>)
Re: Memory leak in vac_update_relstats ?  (Heikki Linnakangas <heikki@enterprisedb.com>)
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [GENERAL] 8.2.4 signal 11 with large transaction
Next
From: Andrew Dunstan
Date:
Subject: Re: Memory leak in vac_update_relstats ?