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.
Advertising
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
