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
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 |