Re: One process per session lack of sharing - Mailing list pgsql-hackers

From Andres Freund
Subject Re: One process per session lack of sharing
Date
Msg-id 20160719003911.3zarkzo7y2y4umci@alap3.anarazel.de
Whole thread Raw
In response to Re: One process per session lack of sharing  (Craig Ringer <craig@2ndquadrant.com>)
List pgsql-hackers
On 2016-07-19 08:33:20 +0800, Craig Ringer wrote:
> On 19 July 2016 at 03:53, Andres Freund <andres@anarazel.de> wrote:
> 
> > On 2016-07-18 15:47:58 -0400, Robert Haas wrote:
> > > I think the risk profile is exactly the opposite of what you are
> > > suggesting here.  If we provide an option to compile the server with
> > > all global variables converted to thread-local variables, there's
> > > really not a whole lot that can break, AFAICS.
> >
> > Using TLS will slow down things noticeably though. So if we were to go
> > there, we'd have to make up for some constant slowdown.
> >
> >
> Does TLS really have more of a performance impact than process context
> switches?

Those aren't really alternatives, unless I'm missing something. You have
context switches between threads as well. They're a bit cheaper (due to
less TLB invalidations), but generally not a *whole* lot.  What TLS
requires is basically for every thread local variable to go through one
(IIRC sometimes two) additional layer of indirection.  For workloads
which are bottlenecked on single core performance (i.e. most of pg,
regardless of parallel query), that can be painful.


Andres



pgsql-hackers by date:

Previous
From: Craig Ringer
Date:
Subject: Re: One process per session lack of sharing
Next
From: Craig Ringer
Date:
Subject: Re: One process per session lack of sharing