Re: [HACKERS] POC: Cache data in GetSnapshotData()

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: [HACKERS] POC: Cache data in GetSnapshotData()
Дата
Msg-id CAB7nPqRDQVo4o7dpJrOaNbb+gVh1xDsdZpJjoDqD_tV2dKdE7Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] POC: Cache data in GetSnapshotData()  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Thu, Sep 21, 2017 at 3:15 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Tue, Aug 29, 2017 at 1:57 AM, Mithun Cy <mithun.cy@enterprisedb.com> wrote:
>> All TPS are median of 3 runs
>> Clients     TPS-With Patch 05   TPS-Base            %Diff
>> 1             752.461117                755.186777          -0.3%
>> 64           32171.296537           31202.153576       +3.1%
>> 128         41059.660769           40061.929658       +2.49%
>>
>> I will do some profiling and find out why this case is not costing us
>> some performance due to caching overhead.
>
> So, this shows only a 2.49% improvement at 128 clients but in the
> earlier message you reported a 39% speedup at 256 clients.  Is that
> really correct?  There's basically no improvement up to threads = 2 x
> CPU cores, and then after that it starts to improve rapidly?  What
> happens at intermediate points, like 160, 192, 224 clients?

It could be interesting to do multiple runs as well, and eliminate
runs with upper and lower bound results while taking an average of the
others. 2/3% is within the noise band of pgbench.
-- 
Michael


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: [HACKERS] [Proposal] Allow users to specify multiple tables inVACUUM commands
Следующее
От: Mithun Cy
Дата:
Сообщение: Re: [HACKERS] POC: Cache data in GetSnapshotData()