Re: Scaling shared buffer eviction

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Mark Kirkwood <mark(dot)kirkwood(at)catalyst(dot)net(dot)nz>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Scaling shared buffer eviction
Date: 2014-09-05 11:50:29
Message-ID: CAA4eK1+7UU0QosLzba86s_aMLL9oTp1qzuE9QcPZQx88Fb0Hmg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Sep 5, 2014 at 8:42 AM, Mark Kirkwood <mark(dot)kirkwood(at)catalyst(dot)net(dot)nz>
wrote:
>
> On 04/09/14 14:42, Amit Kapila wrote:
>>
>> On Thu, Sep 4, 2014 at 8:00 AM, Mark Kirkwood <
mark(dot)kirkwood(at)catalyst(dot)net(dot)nz>
>> wrote:
>>>
>>>
>>>
>>> Hi Amit,
>>>
>>> Results look pretty good. Does it help in the read-write case too?
>>
>>
>> Last time I ran the tpc-b test of pgbench (results of which are
>> posted earlier in this thread), there doesn't seem to be any major
>> gain for that, however for cases where read is predominant, you
>> might see better gains.
>>
>> I am again planing to take that data in next few days.
>>
>
> FWIW below are some test results on the 60 core beast with this patch
applied to 9.4. I'll need to do more runs to iron out the variation,
> but it looks like the patch helps the standard (write heavy) pgbench
workload a little, and clearly helps the read only case.
>

Thanks for doing the test. I think if possible you can take
the performance data with higher scale factor (4000) as it
seems your m/c has 1TB of RAM. You might want to use
latest patch I have posted today.

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jan Wieck 2014-09-05 12:35:11 Re: proposal: plpgsql - Assert statement
Previous Message Amit Kapila 2014-09-05 11:47:49 Re: Scaling shared buffer eviction