Re: Performance degradation in commit ac1d794

On 2016-03-16 15:08:07 -0400, Robert Haas wrote:
> On Wed, Mar 16, 2016 at 2:52 PM, Andres Freund <andres(at)anarazel(dot)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 think we'll basically end up allocating them once for the frequent
callsites.

> > - 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.

So you'd like to get only an event for the FD with data back? Or are you
ok with iterating through hundred elements in an array, to see which are
ready?

Andres