On 19 July 2016 at 03:53, Andres Freund <and...@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

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

Reply via email to