On Nov 1, 2013, at 2:08 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > g.vanluffe...@qipc.com writes: >> int4range ( and any other range function) consumes much memory when used in >> a select statement on a big table. > > The problem is that range_out leaks memory, as a consequence of creating a > number of intermediate strings that it doesn't bother to free. I don't > believe it's the only output function that leaks memory, but it does > so with particular vim: now that we've increased the initial size of > StringInfo buffers, it's probably wasting upwards of 2K per call. > > While we could doubtless hack range_out to release those strings again, > it seems to me that that's just sticking a finger in the dike. I'm > inclined to think that we really ought to solve this class of problems > once and for all by fixing printtup.c to run the output functions in a > temporary memory context, ... > 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.
+1. COPY is actually the case I was worried about… if you're dealing with large amounts of data in other clients ISTM that other things will bottleneck before the extra memory context. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
