Re: Performance degradation in commit ac1d794

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Performance degradation in commit ac1d794
Дата
Msg-id CA+TgmoZa-ey4HkQUQ8GiTYzusK2tELnRG4LFuzarJ8ZhqAvayA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Performance degradation in commit ac1d794  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Performance degradation in commit ac1d794  (Andres Freund <andres@anarazel.de>)
Список 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 по дате отправления:

Предыдущее
От: Catalin Iacob
Дата:
Сообщение: Re: proposal: PL/Pythonu - function ereport
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: pgindent-polluted commits