Re: [BUGS] BUG #8573: int4range memory consumption
От | Jim Nasby |
---|---|
Тема | Re: [BUGS] BUG #8573: int4range memory consumption |
Дата | |
Msg-id | FE8DFBB6-CE61-45FE-BCFE-34E3941D1D37@decibel.org обсуждение исходный текст |
Ответ на | Re: [BUGS] BUG #8573: int4range memory consumption (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [BUGS] BUG #8573: int4range memory consumption
|
Список | pgsql-hackers |
On Nov 1, 2013, at 2:08 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > g.vanluffelen@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 thatother things will bottleneck before the extra memory context.
В списке pgsql-hackers по дате отправления: