Re: Performance degradation in commit ac1d794 - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Performance degradation in commit ac1d794
Date
Msg-id 20151226112248.uv3qxmroe4va7wke@alap3.anarazel.de
Whole thread Raw
In response to Re: Performance degradation in commit ac1d794  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Performance degradation in commit ac1d794  (Andres Freund <andres@anarazel.de>)
Re: Performance degradation in commit ac1d794  (Andres Freund <andres@anarazel.de>)
List 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 by date:

Previous
From: Vladimir Sitnikov
Date:
Subject: Re: [POC] FETCH limited by bytes.
Next
From: Andres Freund
Date:
Subject: Re: Performance degradation in commit ac1d794