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@2ndquadrant.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