Re: Performance degradation in commit ac1d794

On Wed, Mar 16, 2016 at 2:52 PM, Andres Freund <andres@anarazel.de> wrote:
> How about the following sketch of an API
>
> typedef struct LatchEvent
> {
>         uint32 events; /* interesting events */
>         uint32 revents;  /* returned events */
>         int fd; /* fd associated with event */
> } LatchEvent;
>
> typedef struct LatchEventSet
> {
>         int nevents;
>         LatchEvent events[FLEXIBLE_ARRAY_MEMBER];
> } LatchEventSet;
>
> /*
>  * Create a LatchEventSet with space for nevents different events to wait for.
>  *
>  * latch may be NULL.
>  */
> extern LatchEventSet *CreateLatchEventSet(int nevents, Latch *latch);

We might be able to rejigger this so that it didn't require palloc, if
we got rid of FLEXIBLE_ARRAY_MEMBER and passed int nevents and
LatchEvent * separately to WaitLatchThingy().  But I guess maybe this
will be infrequent enough not to matter.

> I've two questions:
> - Is there any benefit of being able to wait for more than one latch?
>   I'm inclined to not allow that for now, that'd make the patch bigger,
>   and I don't see a use-case right now.

I don't see a use case, either.

> - Given current users we don't need a large amount of events, so having
>   to iterate through the registered events doesn't seem bothersome. We
>   could however change the api to be something like
>
>   int WaitLatchEventSet(LatchEventSet *set, OccurredEvents *, int nevents, long timeout);
>
>   which would return the number of events that happened, and would
>   basically "fill" one of the (usually stack allocated) OccurredEvent
>   structures with what happened.

I definitely think something along these lines is useful.  I want to
be able to have an Append node with 100 ForeignScans under it and kick
off all the scans asynchronously and wait for all of the FDs at once.

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