On Wed, Oct 5, 2016 at 12:05 PM, Tomas Vondra <tomas.von...@2ndquadrant.com> wrote: > Hi, > > After collecting a lot more results from multiple kernel versions, I can > confirm that I see a significant improvement with 128 and 192 clients, > roughly by 30%: > > 64 128 192 > ------------------------------------------------ > master 62482 43181 50985 > granular-locking 61701 59611 47483 > no-content-lock 62650 59819 47895 > group-update 63702 64758 62596 > > But I only see this with Dilip's workload, and only with pre-4.3.0 kernels > (the results above are from kernel 3.19). >
That appears positive. > With 4.5.5, results for the same benchmark look like this: > > 64 128 192 > ------------------------------------------------ > master 35693 39822 42151 > granular-locking 35370 39409 41353 > no-content-lock 36201 39848 42407 > group-update 35697 39893 42667 > > That seems like a fairly bad regression in kernel, although I have not > identified the feature/commit causing it (and it's also possible the issue > lies somewhere else, of course). > > With regular pgbench, I see no improvement on any kernel version. For > example on 3.19 the results look like this: > > 64 128 192 > ------------------------------------------------ > master 54661 61014 59484 > granular-locking 55904 62481 60711 > no-content-lock 56182 62442 61234 > group-update 55019 61587 60485 > Are the above results with synchronous_commit=off? > I haven't done much more testing (e.g. with -N to eliminate collisions on > branches) yet, let's see if it changes anything. > Yeah, let us see how it behaves with -N. Also, I think we could try at higher scale factor? -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
