Re: Fw: HACKERS[PATCH] split ProcArrayLock into multiple parts -- follow-up

From: "Jim Van Fleet" <vanfleet(at)us(dot)ibm(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: PostgreSQL-Dev <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Fw: HACKERS[PATCH] split ProcArrayLock into multiple parts -- follow-up
Date: 2017-09-21 21:39:12
Message-ID: OFC4FBF318.31C117B7-ON862581A2.0075A66B-862581A2.0076F10B@notes.na.collabserv.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On 2017-09-21 15:51:54 -0500, Jim Van Fleet wrote:
> > Not to beat on a dead horse, or anything, but this fix was frowned
upon
> > because in one environment (one socket) it was 6% down and over 15% up
in
> > the right environment (two sockets).
>
> > So, why not add a configuration parameter which specifies the number
of
> > parts? Default is 1 which would be "exactly" the same as no parts and
> > hence no degradation in the single socket environment -- and with 2,
you
> > get some positive performance.
>
> Several reasons:
>
> - You'd either add a bunch of branches into a performance critical
> parts, or you'd add a compile time flag, which most people would be
> unable to toggle.
I agree, no compile time flags -- but no extra testing in the main path --
gets set at init and not changed from there.
> - It'd be something hard to tune, because even on multi-socket machines
> it'll be highly load dependant. E.g. workloads that largely are
> bottlenecked in a single backend / few backends will probably regress
> as well.
Workloads are hard to tune -- with the default, you have what you have
today. If you "know" the issue is ProcArrayLock, then you have an
alternative to try.
>
> FWIW, you started a new thread with this message, that doesn't seem
> helpful?

Sorry about that -- my mistake.

Jim

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Daniel Gustafsson 2017-09-21 22:24:30 Commitfest 201709 update
Previous Message Tom Lane 2017-09-21 21:38:13 Re: !USE_WIDE_UPPER_LOWER compile errors in v10+