Re: [HACKERS] Pipelining executions to postgresql server

Поиск
Список
Период
Сортировка
Искать
От
Craig Ringer
Тема
Re: [HACKERS] Pipelining executions to postgresql server
Дата
Msg-id
545881C4.10008@2ndquadrant.com
Ответ на
Список
Дерево обсуждения
Pipelining executions to postgresql server Mikko Tiihonen <Mikko.Tiihonen@nitorcreations.com>
Re: [HACKERS] Pipelining executions to postgresql server Andres Freund <andres@2ndquadrant.com>
Re: [HACKERS] Pipelining executions to postgresql server Mikko Tiihonen <Mikko.Tiihonen@nitorcreations.com>
Re: [HACKERS] Pipelining executions to postgresql server Andres Freund <andres@2ndquadrant.com>
Re: [HACKERS] Pipelining executions to postgresql server Mikko Tiihonen <Mikko.Tiihonen@nitorcreations.com>
Re: [HACKERS] Pipelining executions to postgresql server Craig Ringer <craig@2ndquadrant.com>
Re: [HACKERS] Pipelining executions to postgresql server Mikko Tiihonen <Mikko.Tiihonen@nitorcreations.com>
Re: [HACKERS] Pipelining executions to postgresql server Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Pipelining executions to postgresql server Craig Ringer <craig@2ndquadrant.com>
Re: [HACKERS] Pipelining executions to postgresql server Craig Ringer <craig@2ndquadrant.com>
Re: [HACKERS] Pipelining executions to postgresql server Craig Ringer <craig@2ndquadrant.com>
Re: [HACKERS] Pipelining executions to postgresql server Kevin Wooten <kdubb@me.com>
Re: [HACKERS] Pipelining executions to postgresql server Mikko Tiihonen <Mikko.Tiihonen@nitorcreations.com>
Re: [HACKERS] Pipelining executions to postgresql server Scott Harrington <scotth01@sns-usa.com>
Re: [HACKERS] Pipelining executions to postgresql server Craig Ringer <craig@2ndquadrant.com>
Re: [HACKERS] Pipelining executions to postgresql server Craig Ringer <craig@2ndquadrant.com>
Re: [HACKERS] Pipelining executions to postgresql server Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Pipelining executions to postgresql server Craig Ringer <craig@2ndquadrant.com>
On 11/03/2014 07:05 AM, Scott Harrington wrote:
> This avoids the need for a Future, and avoids the client having to
> loop/sleep until done.

A Future is the logical way to represent an asynchronous operation in
Java. Why implement something else that doesn't fit into existing
libraries and tools when there's already a standard interface?

If you're breaking outside the stock JDBC model and thinking
asynchronously, then using the existing Java APIs for asynchrony makes
sense to me.

In terms of looping until done ... what we really need is a reliably
non-blocking PGConnection.consumeInput() so apps can call that in their
main loops, or via a helper thread. Then we'd be able to add async
notification callbacks too. To do that we need to make PGstream use a
java.nio.Channel instead of a java.net.socket .

-- 
 Craig Ringer                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

В списке pgsql-jdbc по дате отправления
От: Craig Ringer
Дата:
От: Craig Ringer
Дата:
FAQ