From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Васильев Дмитрий <d(dot)vasilyev(at)postgrespro(dot)ru>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Performance degradation in commit ac1d794 |
Date: | 2016-01-14 15:14:43 |
Message-ID: | 19268.1452784483@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)de> writes:
> 0004 currently contains one debatable optimization, which I'd like to
> discuss: Currently the 'sock' passed to WaitLatchOrSocket is not
> removed/added to the epoll fd, if it's the numerically same as in the
> last call. That's good for performance, but would be wrong if the socket
> were close and a new one with the same value would be waited on. I
> think a big warning sign somewhere is sufficient to deal with that
> problem - it's not something we're likely to start doing. And even if
> it's done at some point, we can just offer an API to reset the last used
> socket fd.
Perhaps a cleaner API solution would be to remove the socket argument per
se from the function altogether, instead providing a separate
SetSocketToWaitOn() call.
(Also, if there is a need for it, we could provide a function that still
takes a socket argument, with the understanding that it's to be used for
short-lived sockets where you don't want to change the process's main
epoll state.)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2016-01-14 15:39:55 | Re: Performance degradation in commit ac1d794 |
Previous Message | Andres Freund | 2016-01-14 14:39:31 | Re: Performance degradation in commit ac1d794 |