Re: Disk buffering of resultsets
От | Craig Ringer |
---|---|
Тема | Re: Disk buffering of resultsets |
Дата | |
Msg-id | 54518A31.8010704@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: Disk buffering of resultsets (Vitalii Tymchyshyn <vit@tym.im>) |
Ответы |
Re: Disk buffering of resultsets
|
Список | pgsql-jdbc |
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
В списке pgsql-jdbc по дате отправления: