Re: Disk buffering of resultsets

From: Craig Ringer <craig(at)2ndquadrant(dot)com>
To: Vitalii Tymchyshyn <vit(at)tym(dot)im>, Enrico Olivelli - Diennea <enrico(dot)olivelli(at)diennea(dot)com>
Cc: 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-29 00:45:24
Message-ID: 545038A4.3010100@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc

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

In response to

Responses

Browse pgsql-jdbc by date

  From Date Subject
Next Message Craig Ringer 2014-10-29 06:20:47 Re: Bug in setClob() ?
Previous Message Dave Cramer 2014-10-28 17:47:25 Re: Hung thread