On 2016-07-19 08:33:20 +0800, Craig Ringer wrote: > 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?
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 -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers