Re: Performance degradation in commit ac1d794

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Performance degradation in commit ac1d794
Дата
Msg-id 20151226112248.uv3qxmroe4va7wke@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: Performance degradation in commit ac1d794  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Performance degradation in commit ac1d794  (Andres Freund <andres@anarazel.de>)
Re: Performance degradation in commit ac1d794  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
On 2015-12-25 16:29:53 -0500, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > There's a couple solutions I can think of to that problem:
> > 1) Use epoll()/kqueue, or other similar interfaces that don't require
> >    re-registering fds at every invocation. My guess is that that'd be
> >    desirable for performance anyway.
> 
> Portability, on the other hand, would be problematic.

Indeed. But we might be able to get away with it because there's
realistically just one platform on which people run four socket
servers. Obviously we'd leave poll and select support in place.  It'd be
a genuine improvement for less extreme loads on linux, too.

> > 3) Replace the postmaster_alive_fds socketpair by some other signalling
> >    mechanism. E.g. sending a procsignal to each backend, which sets the
> >    latch and a special flag in the latch structure.
> 
> And what would send the signal?  The entire point here is to notice the
> situation where the postmaster has crashed.  It can *not* depend on the
> postmaster taking some action.

Ahem. Um. Look, over there --->

I blame it on all the food.


Andres



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

Предыдущее
От: Vladimir Sitnikov
Дата:
Сообщение: Re: [POC] FETCH limited by bytes.
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Performance degradation in commit ac1d794