Re: One process per session lack of sharing

On 19 July 2016 at 03:53, Andres Freund <andres(at)anarazel(dot)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?

Genuine question, I'm clueless in the area.

> > We'll technically be multi-threaded but the code need not know or care
> > about the other threads; only in the event of a memory clobber can
> > they affect each other.
>
> But that'll make it pretty hard to take advantage of multi-threading to
> a meaningful degree. Except for being able to create shared memory after
> the fact - quite useful! - there'd not be much point.
>

Yeah. TLS is too simplistic. To do any useful parallel work without
serialization/deserialization, some threads need to be in groups with other
threads, sharing some data structures but having private copies of others.

That said, TLS can be used as a reasonable default state, then individual
data structures extracted and shared more formally when needed. So it's a
sane starting point.

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services