| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, Васильев Дмитрий <d(dot)vasilyev(at)postgrespro(dot)ru>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Performance degradation in commit ac1d794 |
| Date: | 2016-01-14 15:46:00 |
| Message-ID: | 29091.1452786360@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)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...
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2016-01-14 15:56:17 | Re: Performance degradation in commit ac1d794 |
| Previous Message | Robert Haas | 2016-01-14 15:39:55 | Re: Performance degradation in commit ac1d794 |