Re: Protocol 3, Execute, maxrows to return, impact? - Mailing list pgsql-hackers

From Stephen R. van den Berg
Subject Re: Protocol 3, Execute, maxrows to return, impact?
Date
Msg-id 20080713162218.GA2067@cuci.nl
Whole thread Raw
In response to Re: Protocol 3, Execute, maxrows to return, impact?  (Gregory Stark <stark@enterprisedb.com>)
Responses Re: Protocol 3, Execute, maxrows to return, impact?  ("Stephen R. van den Berg" <srb@cuci.nl>)
Re: Protocol 3, Execute, maxrows to return, impact?  ("Stephen R. van den Berg" <srb@cuci.nl>)
List pgsql-hackers
Gregory Stark wrote:
>"Abhijit Menon-Sen" <ams@oryx.com> writes:
>>> Interleaved retrieval using multiple portals is not what most
>>> libraries support, I'd guess.

>> My code did support that mode of operation in theory, but in practice
>> in the few situations where I have needed to use something like it, I
>> found it more convenient to open explicit cursors and FETCH from them

>Note that using FETCH for each record means a round trip to the server for
>each record. If you're dealing with a lot of records that could be a lot
>slower than streaming them to the client as quickly as it can consume them.

>Now I'm not sure anyone's actually done any experiments to optimize libpq or
>other drivers to stream data efficiently, so I'm not sure how much you would
>really lose in practice today.

My Pike drivers now support multiple simultaneous portals and
automatic streaming by presending overlapping Execute statements with
a dynamically adapted fetchlimit calculated per select as the query
progresses.

The only support still lacking is COPY.
-- 
Sincerely,          Stephen R. van den Berg.

In this signature, the concluding three words `were left out'.


pgsql-hackers by date:

Previous
From: "David E. Wheeler"
Date:
Subject: Re: PATCH: CITEXT 2.0 v3
Next
From: "Stephen R. van den Berg"
Date:
Subject: COPY command, support for mixing binary and text columns?