From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Васильев Дмитрий <d(dot)vasilyev(at)postgrespro(dot)ru>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Performance degradation in commit ac1d794 |
Date: | 2015-12-26 11:22:48 |
Message-ID: | 20151226112248.uv3qxmroe4va7wke@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2015-12-25 16:29:53 -0500, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2015-12-26 12:11:14 | Re: Performance degradation in commit ac1d794 |
Previous Message | Vladimir Sitnikov | 2015-12-26 11:16:43 | Re: [POC] FETCH limited by bytes. |