Tom Lane wrote:
> 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.
I played with such a beast last winter. It suits the parser particularly
well, it does a lot of tiny allocations that are all freed together, and
palloc is at the top of the CPU profile. My implementation was a simple
stack-like allocator, with a no-op pfree. I got carried away with other
stuff, but I remember that one difficulty was using a different memory
context for the parser because of the hack in PreventTransactionChain
that checked if a piece of memory was allocated in QueryContext. I'm
glad it's gone.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
