"Tom Lane" <[EMAIL PROTECTED]> writes: > Personally I've been thinking of mounting an effort to get rid of > unnecessary pfree's wherever possible. Particularly in user-defined > functions, "cleaning up" at the end is a waste of code space and > cycles too, because they're typically called in contexts that are > going to be reset immediately afterward.
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. > In the case of vac_update_relstats, it's called only once per > transaction, so there's certainly no point in being a neatnik. > Stuff you need to worry about is functions that might be called > many times in the same memory context. Fwiw there are user-space functions that can't leak memory. I'm sure everyone knows about btree operators, but pgsql also assumes that type input and output functions don't leak memory too (or else assignment leaks memory in the function scope memory context and in a loop...). -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
