On 09/23/2016 02:59 PM, Pavan Deolasee wrote:

On Fri, Sep 23, 2016 at 6:05 PM, Tomas Vondra
<tomas.von...@2ndquadrant.com <mailto:tomas.von...@2ndquadrant.com>> wrote:

    On 09/23/2016 05:10 AM, Amit Kapila wrote:

        On Fri, Sep 23, 2016 at 5:14 AM, Tomas Vondra
        <mailto: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
            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

        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 ...

I see couple of problems with the tests:

1. You're running regular pgbench, which also updates the small
tables. At scale 300 and higher clients, there is going to heavy
contention on the pgbench_branches table. Why not test with pgbench

Sure, I can do a bunch of tests with pgbench -N. Good point.

But notice that I've also done the testing with Dilip's workload, and the results are pretty much the same.


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