Re: Disk buffering of resultsets

From: Craig Ringer <craig(at)2ndquadrant(dot)com>
To: Vitalii Tymchyshyn <vit(at)tym(dot)im>
Cc: Enrico Olivelli - Diennea <enrico(dot)olivelli(at)diennea(dot)com>, John R Pierce <pierce(at)hogranch(dot)com>, PG-JDBC Mailing List <pgsql-jdbc(at)postgresql(dot)org>
Subject: Re: Disk buffering of resultsets
Date: 2014-10-30 00:45:37
Message-ID: 54518A31.8010704@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-jdbc by date

  From Date Subject
Next Message Vitalii Tymchyshyn 2014-10-30 01:33:40 Re: Disk buffering of resultsets
Previous Message Vitalii Tymchyshyn 2014-10-29 23:27:25 Re: Disk buffering of resultsets