Re: Performance degradation in commit ac1d794 - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Performance degradation in commit ac1d794
Date
Msg-id CA+TgmobA7CSJkJpT7cPEkdp8GiwPupbavhe_GKQj+uxYpM=VYA@mail.gmail.com
Whole thread Raw
In response to Re: Performance degradation in commit ac1d794  (Andres Freund <andres@anarazel.de>)
Responses Re: Performance degradation in commit ac1d794
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Performance degradation in commit ac1d794
Next
From: Robert Haas
Date:
Subject: Re: fd.c doesn't remove files on a crash-restart