On Wed, Oct 5, 2016 at 8:18 AM, Tomas Vondra <tomas.von...@2ndquadrant.com> wrote: > Over the past couple of days I've been doing a bit of benchmarking for the > "group clog" patch [1], and I've ran into what I suspect might be a fairly > serious performance regression on newer kernels (essentially 4.3.0 and > newer). I got to a point where I need help with further investigation, > testing on other systems etc. > > The workload tested in the patch [1] is quite simple - a transaction with 3 > x SELECT FOR UPDATE queries and 2 x SAVEPOINT on unlogged tables. The > results (average tps from 5 x 5 minute runs, for 32 and 64 clients) on > multiple kernels look like this: > > kernel 32 64 > --------------------------------- > 3.19.8 48524 59291 > 4.1.33 47193 59574 > 4.2.8 48901 59877 > 4.3.0 32187 38970 > 4.3.6 31889 38815 > 4.4.0 31946 37702 > 4.4.23 31498 37724 > 4.5.5 31531 37351 > 4.7.6 32859 38490
Just stumbled upon this old thread. Since the regression is very clear and reproduceable and on a vanilla kernel I don't think you need more testing. The kernel devs or at least Linus take regressions (including performance) very seriously, even if it's theoretically not the kernel's fault (so in this case regardless what Postgres is doing). I think you should just report it to lkml. If you have time to do a bisection between 4.2.8 and 4.3.0 and find the offending commit that would be even better, then email the author and CC lkml and Linus, that should be enough to get it fixed. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
