Re: Possible performance regression in version 10.1 with pgbenchread-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@gmail.com> wrote:
> > > On Wed, Feb 21, 2018 at 10:03 PM, Mithun Cy <mithun.cy@enterprisedb.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@sss.pgh.pa.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