Re: Scaling shared buffer eviction

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: Scaling shared buffer eviction
Дата
Msg-id CAA4eK1+7UU0QosLzba86s_aMLL9oTp1qzuE9QcPZQx88Fb0Hmg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Scaling shared buffer eviction  (Mark Kirkwood <mark.kirkwood@catalyst.net.nz>)
Ответы Re: Scaling shared buffer eviction  (Mark Kirkwood <mark.kirkwood@catalyst.net.nz>)
Список pgsql-hackers
On Fri, Sep 5, 2014 at 8:42 AM, Mark Kirkwood <mark.kirkwood@catalyst.net.nz> wrote:
>
> On 04/09/14 14:42, Amit Kapila wrote:
>>
>> On Thu, Sep 4, 2014 at 8:00 AM, Mark Kirkwood <mark.kirkwood@catalyst.net.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

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: Scaling shared buffer eviction
Следующее
От: Jan Wieck
Дата:
Сообщение: Re: proposal: plpgsql - Assert statement