On 09/23/2016 05:10 AM, Amit Kapila wrote:
On Fri, Sep 23, 2016 at 5:14 AM, Tomas Vondra
<tomas.von...@2ndquadrant.com> wrote:
On 09/21/2016 08:04 AM, Amit Kapila wrote:

(c) Although it's not visible in the results, 4.5.5 almost perfectly
eliminated the fluctuations in the results. For example when 3.2.80 produced
this results (10 runs with the same parameters):

    12118 11610 27939 11771 18065
    12152 14375 10983 13614 11077

we get this on 4.5.5

    37354 37650 37371 37190 37233
    38498 37166 36862 37928 38509

Notice how much more even the 4.5.5 results are, compared to 3.2.80.

how long each run was?  Generally, I do half-hour run to get stable results.

10 x 5-minute runs for each client count. The full shell script driving the benchmark is here: http://bit.ly/2doY6ID and in short it looks like this:

    for r in `seq 1 $runs`; do
        for c in 1 8 16 32 64 128 192; do
            psql -c checkpoint
            pgbench -j 8 -c $c ...

It of course begs the question what kernel version is running on
the machine used by Dilip (i.e. cthulhu)? Although it's a Power
machine, so I'm not sure how much the kernel matters on it.

cthulhu is a x86 m/c and the kernel version is 3.10. Seeing, the
above results I think kernel version do matter, but does that mean
we ignore the benefits we are seeing on somewhat older kernel
version. I think right answer here is to do some experiments which
can show the actual contention as suggested by Robert and you.

Yes, I think it'd be useful to test a new kernel version. Perhaps try 4.5.x so that we can compare it to my results. Maybe even try using my shell script

There are results for 64, 128 and 192 clients. Why should we care
about numbers in between? How likely (and useful) would it be to
get improvement with 96 clients, but no improvement for 64 or 128

The only point to take was to see from where we have started seeing
improvement, saying that the TPS has improved from >=72 client count
is different from saying that it has improved from >=128.

I find the exact client count rather uninteresting - it's going to be quite dependent on hardware, workload etc.

I don't dare to suggest rejecting the patch, but I don't see how
we could commit any of the patches at this point. So perhaps
"returned with feedback" and resubmitting in the next CF (along
with analysis of improvedworkloads) would be appropriate.

Agreed with your conclusion and changed the status of patch in CF


Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

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

Reply via email to