Re: POC: Cache data in GetSnapshotData()

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Mithun Cy <mithun(dot)cy(at)enterprisedb(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: POC: Cache data in GetSnapshotData()
Date: 2017-09-21 01:15:50
Message-ID: CAB7nPqRDQVo4o7dpJrOaNbb+gVh1xDsdZpJjoDqD_tV2dKdE7Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Sep 21, 2017 at 3:15 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Tue, Aug 29, 2017 at 1:57 AM, Mithun Cy <mithun(dot)cy(at)enterprisedb(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Mithun Cy 2017-09-21 01:46:54 Re: POC: Cache data in GetSnapshotData()
Previous Message Michael Paquier 2017-09-21 00:58:28 Re: [Proposal] Allow users to specify multiple tables in VACUUM commands