Re: One process per session lack of sharing

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

In response to

Browse pgsql-hackers by date

  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