Hi!
On Mon, Jul 9, 2018 at 6:19 AM Imai, Yoshikazu
<imai.yoshikazu@jp.fujitsu.com> wrote:
> Hi, I'm reviewing this.
Great. Thank you for giving attention to this patch.
> Firstly, I did performance tests on 72-cores machines(AWS c5.18xlarge) same as you did.
OK. But not that c5.18xlarge is 72-VCPU machine, which AFAIK is close
to the performance of 36 physical cores.
> > # results
> > ordered, master: 157473 TPS
> > ordered, patched 231374 TPS
> > unordered, master: 232372 TPS
> > unordered, patched: 232535 TPS
>
> # my results
> ordered, master: 186045 TPS
> ordered, patched: 265842 TPS
> unordered, master: 313011 TPS
> unordered, patched: 309636 TPS
>
> I confirmed that this patch improves ordered insertion.
Good, but it seems like 1% regression in unordered case.
> In addition to your tests, I did the following tests with many duplicate entries
>
> # DDL
> CREATE UNLOGGED TABLE duplicated (i integer not null, value text not null);
>
> # script_duplicated.sql
> INSERT INTO unordered VALUES (1, 'abcdefghijklmnoprsqtuvwxyz');
>
> # commands
> pgbench -T 60 -P 1 -M prepared -f script_duplicated.sql -c 150 -j 150 postgres
>
> # results
> duplicated, master: 315450 TPS
> duplicated, patched: 311584 TPS
>
> It seems there are almostly no performance degression in case of many duplicated entries.
In this case it also looks like we observed 1% regression. Despite 1%
may seem to be very small, I think we should clarify whether it really
exists. I have at least two hypothesis about this.
1) There is no real regression, observed difference of TPS is less
than error of measurements. In order to check that we need to retry
the experiment multiple times. Also, if you run benchmark on master
before patched version (or vice versa) you should also try to swap the
order to make sure there is no influence of the order of benchmarks.
2) If we consider relation between TPS and number of clients, TPS is
typically growing with increasing number of clients until reach some
saturation value. After the saturation value, there is some
degradation of TPS. If patch makes some latency lower, that my cause
saturation to happen earlier. In order to check that, we need run
benchmarks with various number of clients and draw a graph: TPS
depending on clients.
So, may I ask you to make more experiments in order to clarify the
observed regression?
------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
