On Mon, Nov 4, 2013 at 10:51 PM, Amit Kapila amit.kapil...@gmail.com wrote:
On Tue, Nov 5, 2013 at 12:52 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Amit Kapila amit.kapil...@gmail.com writes:
On Mon, Nov 4, 2013 at 8:15 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Really I'd like to see standalone mode,
On 2013-11-02 15:29:36 -0400, Tom Lane wrote:
Attached is a proposed patch for this. It fixes most of the functions
in printtup.c to use a per-row memory context. (I did not bother to
fix debugtup(), which is used only in standalone mode. If you're doing
queries large enough for mem leaks
Andres Freund and...@2ndquadrant.com writes:
On 2013-11-02 15:29:36 -0400, Tom Lane wrote:
Attached is a proposed patch for this. It fixes most of the functions
in printtup.c to use a per-row memory context. (I did not bother to
fix debugtup(), which is used only in standalone mode. If
On 2013-11-04 09:45:22 -0500, Tom Lane wrote:
Really I'd like to see standalone mode, in its current form, go away
completely. I had a prototype patch for allowing psql and other clients
to interface to a standalone backend. I think getting that finished would
be a way more productive use of
On Mon, Nov 4, 2013 at 8:15 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2013-11-02 15:29:36 -0400, Tom Lane wrote:
Attached is a proposed patch for this. It fixes most of the functions
in printtup.c to use a per-row memory context. (I did not bother
Amit Kapila amit.kapil...@gmail.com writes:
On Mon, Nov 4, 2013 at 8:15 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Really I'd like to see standalone mode, in its current form, go away
completely. I had a prototype patch for allowing psql and other clients
to interface to a standalone backend. I
On Tue, Nov 5, 2013 at 12:52 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Amit Kapila amit.kapil...@gmail.com writes:
On Mon, Nov 4, 2013 at 8:15 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Really I'd like to see standalone mode, in its current form, go away
completely. I had a prototype patch for
Jim Nasby deci...@decibel.org writes:
On Nov 1, 2013, at 2:08 PM, Tom Lane t...@sss.pgh.pa.us wrote:
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
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
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
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
11 matches
Mail list logo
