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

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/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