Re: One process per session lack of sharing

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: One process per session lack of sharing
Дата
Msg-id 20160719003911.3zarkzo7y2y4umci@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: One process per session lack of sharing  (Craig Ringer <craig@2ndquadrant.com>)
Список pgsql-hackers
On 2016-07-19 08:33:20 +0800, Craig Ringer wrote:
> On 19 July 2016 at 03:53, Andres Freund <andres@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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Craig Ringer
Дата:
Сообщение: Re: One process per session lack of sharing
Следующее
От: Craig Ringer
Дата:
Сообщение: Re: One process per session lack of sharing