Re: Performance degradation in commit ac1d794

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