From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Jan Wieck <jan(at)wi3ck(dot)info>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, AMatveev(at)bitec(dot)ru, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: One process per session lack of sharing |
Date: | 2016-07-19 00:39:11 |
Message-ID: | 20160719003911.3zarkzo7y2y4umci@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2016-07-19 08:33:20 +0800, Craig Ringer wrote:
> 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?
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
From | Date | Subject | |
---|---|---|---|
Next Message | Craig Ringer | 2016-07-19 00:56:27 | Re: One process per session lack of sharing |
Previous Message | Craig Ringer | 2016-07-19 00:33:20 | Re: One process per session lack of sharing |