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

From: Andres Freund <andres(at)anarazel(dot)de>
To: Jim Van Fleet <vanfleet(at)us(dot)ibm(dot)com>
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 20:57:31
Message-ID: 20170921205731.omxufnitbcp37gsb@alap3.anarazel.de
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.
- 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.

FWIW, you started a new thread with this message, that doesn't seem
helpful?

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2017-09-21 21:03:13 Re: visual studio 2017 build support
Previous Message Peter Geoghegan 2017-09-21 20:55:53 Re: CREATE COLLATION does not sanitize ICU's BCP 47 language tags. Should it?