From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | g(dot)vanluffelen(at)qipc(dot)com, pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [BUGS] BUG #8573: int4range memory consumption |
Date: | 2013-11-02 00:17:00 |
Message-ID: | 11501.1383351420@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | mgr inż. Jacek Bzdak | 2013-11-02 00:17:59 | Problems with pg_stat_activity view |
Previous Message | Tomas Vondra | 2013-11-02 00:16:09 | Re: array_agg() on a set larger than some arbitrary(?) limit causes runaway memory usage and eventually memory exhaustion |
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2013-11-02 01:02:12 | appendPQExpBufferVA vs appendStringInfoVA |
Previous Message | Atri Sharma | 2013-11-01 22:43:26 | Re: Feature request: Optimizer improvement |