On 2016-04-13 15:21:31 -0500, Kevin Grittner wrote: > On Wed, Apr 13, 2016 at 3:01 PM, Andres Freund <and...@anarazel.de> wrote: > > > If you want me to rn some other tests I can, but ISTM we have the > > data we need? > > Thanks for the additional detail on how this was run. I think I > still need a little more context, though: > > What is the kernel on which these tests were run?
3.16. I can upgrade to 4.4 if necessary. But I still believe very strongly that this is side-tracking the issue. An exclusive lock (or spinlock) in a very hot path, which previously didn't have a specific exclusively locked lock, will present scalability issues, regardless of kernel. > Which pg commit were these tests run against? 85e00470. + some reverts (the whitespace commits make this harder...) in the reverted case. > If 2201d801 was not included in your -1 tests, have you identified > where the 2% extra run time is going on -1 versus reverted? No. It's hard to do good profiles on most virtualized hardware, since hardware performance counters are disabled. So you only can do OS sampling; which has a pretty big performance influence. I'm not entirely sure what you mean with "2201d801 was not included in your -1 tests". The optimization was present. > Since several other threads lately have reported bigger variation than > that based on random memory alignment issues, can we confirm that this > is a real difference in what is at master's HEAD? It's unfortunately hard to measure this conclusively here (and in general). I guess we'll have to look, on native hardware, where the difference comes from. The difference is smaller on my laptop, and my workstation is somewhere on a container ship, other physical hardware I do not have. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
