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 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
