On Thu, Mar 24, 2011 at 9:09 PM, Oliver Jowett <oliver@opencloud.com> wrote:
> On 25 March 2011 13:40, Dave Cramer <pg@fastcrypt.com> wrote:
>> It was suggested by Robert Haas that it would be possible to return
>> from a query immediately instead of reading the entire result set.
>> Instead of reading it we just let the O/S buffer the results until we
>> get around to reading it. Before I go to the trouble of prototyping
>> this can anyone see a reason why this wouldn't work ?
>
> What happens if the app then wants to run another query before reading
> the resultset? One common case is going to be run query - inspect
> resultset metadata - driver has to run internal queries to return that
> metadata. I'm a little worried about error handling too.
>
> For queries in a transaction, it might make sense to implement this
> via portals, much as done for fetchsize (i.e. always ask for only 1
> row initially, and read that immediately; then reading the resultset
> beyond the first row triggers a fetch of the rest of the resultset as
> if you had set a large fetchsize). Then you don't have to worry about
> tying up the connection with an unread resultset. Though this means
> you have to use a named statement and lose the unnamed statement
> planning tweaks; and you will have to wait for the query to produce at
> least one row before returning.
>
> There are various things that the wire protocol / backend could do
> better here - a portal equivalent to DECLARE CURSOR WITH HOLD, and
> some way to say "defer planning on this named statement until Bind
> please", would both be useful.
>
> Oliver
I've included Robert on this email as he intimated that he if protocol
changes were made he would be interested in implementing them.
Dave
>
