I wrote: > It's possible that this would result in some net slowdown in tuple output; > but it's also possible that eliminating the retail pfree's in favor of a > single context reset per tuple would make for a net savings. In any case, > we're already using a reset-per-row approach to memory management of > output function calls in COPY OUT, and I know for a fact that we've > squeezed that code path as hard as we could.
It appears that indeed, the reset-per-row approach is marginally faster than the existing code. It's just barely faster with a couple of columns of output, for instance I get about 660 vs 665 msec for select x,x from generate_series(1,1000000) x; but the advantage grows for more columns, which is expected since we're getting rid of more pfree's. With ten integer columns I see 1650 vs 1710 msec, for example. So I see no downside to fixing it like this, and will work on a complete patch. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers