Re: Speed up Clog Access by increasing CLOG buffers

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