Tom Lane wrote: > Gregory Stark <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
