Re: Performance degradation in commit ac1d794

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

In response to

Responses

Browse pgsql-hackers by date

  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.