Kevin Wooten wrote:
> > On Nov 4, 2014, at 12:55 AM, Craig Ringer wrote:
> >
> > I have to say I like some aspects of how pgjdbc-ng is being done - in
> > particular use of Maven and being built around non-blocking I/O.
> >
> > OTOH, the use of Google Guava I find pretty inexplicable in a JDBC
>
> On Nov 4, 2014, at 12:55 AM, Craig Ringer wrote:
>
> On 11/04/2014 07:56 AM, Mikko Tiihonen wrote:
>> I also think the async I/O is the way to go. Luckily that has already been
>> done
>> in the pgjdbc-ng (https://github.com/impossibl/pgjdbc-ng), built on top
>> of netty java NIO library. It
On 11/04/2014 07:56 AM, Mikko Tiihonen wrote:
> I also think the async I/O is the way to go. Luckily that has already been
> done
> in the pgjdbc-ng (https://github.com/impossibl/pgjdbc-ng), built on top
> of netty java NIO library. It has quite good feature parity with the original
> pgjdbc driv
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
On 11/04/2014 07:56 AM, Mikko Tiihonen wrote:
> I do not quite grasp why not sending Sync is so important.
Well, at the moment the PgJDBC driver relies on the following flow to
manage its buffers and avoid a logjam where both server and client are
waiting for the other to consume input:
* Send so
On 11/03/2014 07:05 AM, Scott Harrington wrote:
> I looked over your patch. Your list of ResultHandlerHolders seems to be
> the right direction, but as Tom Lane mentioned there may need to be some
> way to ensure the statements are all in the same transaction.
Why go down this track, when we alre
On 11/04/2014 09:10 AM, Tom Lane wrote:
> Mikko Tiihonen writes:
>> I do not quite grasp why not sending Sync is so important. My proof of
>> concept setup was for queries with autocommit enabled.
>
> [snip] It'll be very much like
> sending a fixed (predetermined) SQL script to the server using
Mikko Tiihonen writes:
> I do not quite grasp why not sending Sync is so important. My proof of
> concept setup was for queries with autocommit enabled.
The point is that that will be very, very much harder to use than doing
it the other way. It's fairly easy to reason about the results of
sing
> Craig Ringer wrote:
> On 11/02/2014 09:27 PM, Mikko Tiihonen wrote:
> > Is the following summary correct:
> > - the network protocol supports pipelinings
> Yes.
>
> All you have to do is *not* send a Sync message and be aware that the
> server will discard all input until the next Sync, so pipel
On 11/02/2014 09:27 PM, Mikko Tiihonen wrote:
> Is the following summary correct:
> - the network protocol supports pipelinings
Yes.
All you have to do is *not* send a Sync message and be aware that the
server will discard all input until the next Sync, so pipelining +
autocommit doesn't make a t
On 11/01/2014 10:04 PM, Mikko Tiihonen wrote:
> Hi,
>
> I created a proof of concecpt patch for postgresql JDBC driver that allows
> the caller to do pipelining of requests within a transaction. The pipelining
> here means same as for HTTP: the client can send the next execution already
> befor
On 2014-11-01 14:04:05 +, Mikko Tiihonen wrote:
I created a proof of concecpt patch for postgresql JDBC driver that
allows the caller to do pipelining of requests within a
transaction. The pipelining here means same as for HTTP: the client
can send the next execution already before waiting fo
> > > From: Andres Freund
> > > On 2014-11-01 14:04:05 +, Mikko Tiihonen wrote:
> > > > I created a proof of concecpt patch for postgresql JDBC driver that
> > > > allows the caller to do pipelining of requests within a
> > > > transaction. The pipelining here means same as for HTTP: the clien
On 2014-11-02 12:11:49 +, Mikko Tiihonen wrote:
> > From: Andres Freund
> > On 2014-11-01 14:04:05 +, Mikko Tiihonen wrote:
> > > I created a proof of concecpt patch for postgresql JDBC driver that
> > > allows the caller to do pipelining of requests within a
> > > transaction. The pipelin
> From: Andres Freund
> On 2014-11-01 14:04:05 +, Mikko Tiihonen wrote:
> > I created a proof of concecpt patch for postgresql JDBC driver that
> > allows the caller to do pipelining of requests within a
> > transaction. The pipelining here means same as for HTTP: the client
> > can send the n
On 2014-11-01 14:04:05 +, Mikko Tiihonen wrote:
> I created a proof of concecpt patch for postgresql JDBC driver that
> allows the caller to do pipelining of requests within a
> transaction. The pipelining here means same as for HTTP: the client
> can send the next execution already before wait
Mikko Tiihonen writes:
> I created a proof of concecpt patch for postgresql JDBC driver that allows
> the caller to do pipelining of requests within a transaction. The pipelining
> here means same as for HTTP: the client can send the next execution already
> before waiting for the response of t
Hi,
I created a proof of concecpt patch for postgresql JDBC driver that allows the
caller to do pipelining of requests within a transaction. The pipelining here
means same as for HTTP: the client can send the next execution already before
waiting for the response of the previous request to be f
18 matches
Mail list logo
