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

From Robert Haas
Subject Re: Performance degradation in commit ac1d794
Date
Msg-id CA+TgmoZa-ey4HkQUQ8GiTYzusK2tELnRG4LFuzarJ8ZhqAvayA@mail.gmail.com
Whole thread Raw
In response to Re: Performance degradation in commit ac1d794  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Performance degradation in commit ac1d794
List pgsql-hackers
On Thu, Jan 14, 2016 at 10:46 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> Incidentally, if we're going to whack around the latch API, it would
>> be nice to pick a design which wouldn't be too hard to extend to
>> waiting on multiple sockets.  The application I have in mind is to
>> send of queries to several foreign servers at once and then wait until
>> bytes come back from any of them.  It's mostly pie in the sky at this
>> point, but it seems highly likely to me that we'd want to do such a
>> thing by waiting for bytes from any of the sockets involved OR a latch
>> event.
>
> Instead of SetSocketToWaitOn, maybe AddSocketToWaitSet and
> RemoveSocketFromWaitSet?  And you'd need some way of identifying
> which socket came ready after a wait call...

Yeah.  Although I think for now it would be fine to just error out if
somebody tries to add a socket and there already is one.  Then we
could lift that limitation in a later commit.  Of course if Andres
wants to do the whole thing now I'm not going to get in the way, but
since that will require Windows tinkering and so on it may be more
than he wants to dive into.

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



pgsql-hackers by date:

Previous
From: Catalin Iacob
Date:
Subject: Re: proposal: PL/Pythonu - function ereport
Next
From: Andrew Dunstan
Date:
Subject: Re: pgindent-polluted commits