Re: Disk buffering of resultsets

Sure, it's fetching fetchSize into heap before switching to a file.
As of application, well, JDBC provides autocommit mode, so there are
applications using it.

As of the second connection, I've got a funny deadlock once with the double
connection architecture. N threads of application got N connections from a
N-limited connection pool and were waiting each for another connection that
just was not available.

Best regards, Vitalii Tymchyshyn
29 жовт. 2014 20:46, користувач "Craig Ringer" <craig(at)2ndquadrant(dot)com>
написав:

> On 10/30/2014 07:27 AM, Vitalii Tymchyshyn wrote:
> > 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.
>
> OK, that's a bit saner, at least if you fetch small results to the heap
> then switch to file storage at some threshold.
>
> > 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.
>
> What I'm asking is why the *application* doesn't just use multiple
> connections or use a transaction with portals.
>
> It's not clear to me why it's worth the complexity in the driver to work
> around what seems like problematic application behaviour.
>
> --
> Craig Ringer http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Training & Services
>