From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Tomas Vondra <tv(at)fuzzy(dot)cz>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: 9.5: Better memory accounting, towards memory-bounded HashAgg |
Date: | 2014-11-17 16:08:53 |
Message-ID: | CA+U5nM+7Z+JZQkYuF62Du2xGJJg65qo5NAvpHQ+V_xGMQPNA2A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 17 November 2014 07:31, Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
> On Sat, 2014-11-15 at 21:36 +0000, Simon Riggs wrote:
>> Do I understand correctly that we are trying to account for exact
>> memory usage at palloc/pfree time? Why??
>
> Not palloc chunks, only tracking at the level of allocated blocks (that
> we allocate with malloc).
>
> It was a surprise to me that accounting at that level would have any
> measurable impact, but Robert found a reasonable case on a POWER machine
> that degraded a couple percent. I wasn't able to reproduce it
> consistently on x86.
Surprise to me also.
Robert's tests showed a deviation of 0.4 sec after a restart. ISTM
that we wouldn't see that every time.
AFAIK the whole purpose of the memory allocator is to reduce the
number of system calls, so if we are doing so many malloc() calls as
to be noticeable just for accounting then something is wrong.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2014-11-17 16:13:15 | double counting of lines in psql |
Previous Message | Robert Haas | 2014-11-17 16:06:05 | Re: REINDEX CONCURRENTLY 2.0 |