Re: Disk buffering of resultsets
От | Vitalii Tymchyshyn |
---|---|
Тема | Re: Disk buffering of resultsets |
Дата | |
Msg-id | CABWW-d01p4gA2q+UQGHQu0MvJOaGy6jxF5BwpdRKjnssRDJ6cQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Disk buffering of resultsets (Craig Ringer <craig@2ndquadrant.com>) |
Ответы |
Re: Disk buffering of resultsets
|
Список | pgsql-jdbc |
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@2ndquadrant.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@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc
В списке pgsql-jdbc по дате отправления: