Re: [HACKERS] Re: pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold <

On 2016-04-13 15:21:31 -0500, Kevin Grittner wrote:
> On Wed, Apr 13, 2016 at 3:01 PM, Andres Freund <andres(at)anarazel(dot)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