Re: Performance degradation in commit ac1d794

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Performance degradation in commit ac1d794
Дата
Msg-id 24833.1451078993@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
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.

> 2) Create a pair of fds between postmaster/backend for each
>    backend. While obviously increasing the the number of FDs noticeably,
>    it's interesting for other features as well: If we ever want to do FD
>    passing from postmaster to existing backends, we're going to need
>    that anyway.

Maybe; it'd provide another limit on how many backends we could run.

> 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.
        regards, tom lane



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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Performance degradation in commit ac1d794
Следующее
От: Jeff Janes
Дата:
Сообщение: 9.5rc1 brin_summarize_new_values