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

From Robert Haas
Subject Re: Performance degradation in commit ac1d794
Date
Msg-id CA+TgmoaPxLXvnADvE4dBaXrFJb+LU29v1sV8JC2F-ytojmJO9A@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
Re: Performance degradation in commit ac1d794
List pgsql-hackers
On Wed, Mar 16, 2016 at 3:25 PM, Andres Freund <andres@anarazel.de> wrote:
>> > - 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?

I'd like to get an event back for the FD with data.  Iterating sounds
like it could be really slow.  Say you get lots of little packets back
from the same connection, while the others are idle.  Now you've got
to keep iterating through them all over and over again.  Blech.

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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [PATCH] Integer overflow in timestamp[tz]_part() and date/time boundaries check
Next
From: otheus uibk
Date:
Subject: Re: async replication code