Re: Disk buffering of resultsets

The fetching time is fully defined by a strategy that will be introduced
after step (2) is complete. Currently it's fully fetched on execute of the
first query, the main difference is that it's copied into a file and not
heap.

As of multiple portals, we are talking about autocommit mode. It's mostly
about supporting this mode and not forcing user to start a transaction or
opening another connection. And I am against the idea of driver making
multiple connections as it will screw up a lot of connection pooling
scenarios and setups.

Best regards, Vitalii Tymchyshyn

2014-10-28 20:45 GMT-04:00 Craig Ringer <craig(at)2ndquadrant(dot)com>:

> On 10/21/2014 10:19 AM, Vitalii Tymchyshyn wrote:
> > Hello, all.
> >
> > Basically, alpha of p.1 is available
> > here: https://github.com/tivv/pgjdbc/tree/offloading
> > It passes all the tests of cursor-based implementation, but I want to
> > add some more (mostly with multiple open statements).
>
> I'm still not sure I fully see the benefits of this, or at least see
> them as worth the complexity introduced.
>
> I'm strongly opposed to the idea of finishing fetching when the next
> statement is created, then stashing any resulting exception in the prior
> statement so it's handled at close time or on the next resultset fetch.
>
> If you don't do that, and instead require that the caller fully fetch
> the resultset before starting the next statement (possibly via a helper
> thread) then it might be more OK.
>
> Overall though, I'm finding it hard to understand the use case for this.
> Why use this instead of multiple portals in an open transaction, or
> multiple connections?
>
> --
> Craig Ringer http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Training & Services
>
>
> --
> Sent via pgsql-jdbc mailing list (pgsql-jdbc(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-jdbc
>