Re: Possible performance regression in version 10.1 with pgbench read-write tests.

Hi,

On 2018-07-19 15:39:44 -0400, Alvaro Herrera wrote:
> On 2018-Jul-19, Amit Kapila wrote:
>
> > On Thu, Feb 22, 2018 at 7:55 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> > > On Wed, Feb 21, 2018 at 10:03 PM, Mithun Cy <mithun(dot)cy(at)enterprisedb(dot)com> wrote:
> > >> seeing futex in the call stack andres suggested that following commit could
> > >> be the reason for regression
> > >>
> > >> commit ecb0d20a9d2e09b7112d3b192047f711f9ff7e59
> > >> Author: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
> > >> Date: 2016-10-09 18:03:45 -0400
> > >>
> > >> Use unnamed POSIX semaphores, if available, on Linux and FreeBSD.
>
> > > Hmm. So that commit might not have been the greatest idea.
> >
> > It appears so. I think we should do something about it as the
> > regression is quite noticeable.
>
> So the fix is just to revert the change for the linux makefile? Sounds
> easy enough, code-wise. Do we need more evidence that it's harmful?
>
> Since it was changed in pg10 not 11, I don't think this is an open-item
> per se. (Maybe an "older bug", if we must really have it there.)

I'm a bit hesitant to just revert without further evaluation - it's just
about as likely we'll regress on other hardware / kernel
versions. Except it'd be in a minor release, whereas the current issue
was in a major release. It'd also suddenly make some installations not
start, due to sysv semaphore # limitations.

There've been a few annoying, and a few embarassing, issues with
futexes, but they receive far more attention from a performance POV.

Greetings,

Andres Freund