Re: Performance degradation in commit ac1d794

On Thu, Jan 14, 2016 at 10:56 AM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> So, I'm wondering how we'd exactly use a hyptothetical
> SetSocketToWaitOn, or SetSocketsToWaitOn (or whatever). I mean it can
> make a fair bit of sense to sometimes wait on MyLatch/port->sock and
> sometimes on MyLatch/fdw connections. The simple proposed code would
> change the epoll set whenever switching between both, but with
> SetSocketsToWaitOn you'd probably end up switching this much more often?
>
> One way to address that would be to create a 'latch wait' datastructure,
> that'd then contain the epoll fd/win32 wait events/... That way you
> could have one 'LatchWait' for latch + client socket and one for latch +
> fdw sockets.

I see your point. As far as I can see, it's currently true that,
right now, the only places where we wait for a socket are places where
the socket will live for the lifetime of the backend, but I think we
should regard it as likely that, in the future, we'll want to use it
anywhere we want to wait for a socket to become ready. There are
getting to be a lot of places where we need to unstick some loop
whenever the process latch gets set, and it seems likely to me that
needs will only continue to grow. So the API should probably
contemplate that sort of need.

I think your idea of a data structure the encapsulates a set of events
for which to wait is probably a good one. WaitLatch doesn't seem like
a great name. Maybe WaitEventSet, and then we can have
WaitLatch(&latch) and WaitEvents(&eventset).

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company