Re: [BUGS] BUG #8573: int4range memory consumption

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

In response to

Browse pgsql-bugs by date

  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

Browse pgsql-hackers by date

  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