From: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
---|---|
To: | Dave Cramer <pg(at)fastcrypt(dot)com>, Vitalii Tymchyshyn <vit(at)tym(dot)im> |
Cc: | Enrico Olivelli - Diennea <enrico(dot)olivelli(at)diennea(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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-21 12:48:06 |
Message-ID: | 54465606.6090602@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
On 10/21/2014 07:06 PM, Dave Cramer wrote:
> Hi Vitalii,
>
> Thanks for this. I am headed for pgconf, hopefully I will have time to
> look at it on the plane.
Great that you're coming.
I'm still concerned by this patch, particularly the fact that it doesn't
properly use partial result set fetching at the protocol level, or
didn't last time I looked.
I really think it should be restricted to v3 protocol support and use
partial EXECUTE.
I'm generally opposed to the idea of the next query incurring the cost
of fetching remaining results from the prior one, and possibly throwing
an unrelated exception. That's IMO just wrong.
I'm not at all convinced we shouldn't be using server-side portals, and
possibly a client-supplied helper thread pool. I really don't like
hijacking a possibly unrelated thread (that's trying to run the next
statement) to do work deferred by a prior connection.
Instead we should probably:
WARNING: Discarding unfetched results from prior connection
HINT: To avoid this warning, explicitly close() the result set or
fully read it before running a new statement.
or even make it an ERROR.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Vitalii Tymchyshyn | 2014-10-21 21:43:54 | Re: Disk buffering of resultsets |
Previous Message | Dave Cramer | 2014-10-21 11:15:14 | Re: Adding support for batches that return generated keys |