On 09/26/2016 08:48 PM, Tomas Vondra wrote:
On 09/26/2016 07:16 PM, Tomas Vondra wrote:

The averages (over the 10 runs, 5 minute each) look like this:

 3.2.80                 1      8     16     32     64    128    192
--------------------------------------------------------------------
 granular-locking    1567  12146  26341  44188  43263  49590  15042
 no-content-lock     1567  12180  25549  43787  43675  51800  16831
 group-update        1550  12018  26121  44451  42734  51455  15504
 master              1566  12057  25457  42299  42513  42562  10462

 4.5.5                  1      8     16     32     64    128    192
--------------------------------------------------------------------
 granular-locking    3018  19031  27394  29222  32032  34249  36191
 no-content-lock     2988  18871  27384  29260  32120  34456  36216
 group-update        2960  18848  26870  29025  32078  34259  35900
 master              2984  18917  26430  29065  32119  33924  35897


So, I got the results from 3.10.101 (only the pgbench data), and it looks like this:

 3.10.101               1      8     16     32     64    128    192
--------------------------------------------------------------------
 granular-locking    2582  18492  33416  49583  53759  53572  51295
 no-content-lock     2580  18666  33860  49976  54382  54012  51549
 group-update        2635  18877  33806  49525  54787  54117  51718
 master              2630  18783  33630  49451  54104  53199  50497

So 3.10.101 performs even better tnan 3.2.80 (and much better than 4.5.5), and there's no sign any of the patches making a difference.

It also seems there's a major regression in the kernel, somewhere between 3.10 and 4.5. With 64 clients, 3.10 does ~54k transactions, while 4.5 does only ~32k - that's helluva difference.

I wonder if this might be due to running the benchmark on unlogged tables (and thus not waiting for WAL), but I don't see why that should result in such drop on a new kernel.

In any case, this seems like an issue unrelated to the patch, so I'll post further data into a new thread instead of hijacking this one.

regards

--
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:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to