Re: Not fetching the entire result set when using holdable cursors

On Wed, 14 May 2008, Arie Ozarov wrote:

> Are there any plans to support holdable cursors without loading the 
> entire data-set (which can potentially be very big)?

There are no immediate plans.  Right now the way cursors are created on 
the server is via the frontend/backend protocol not a DECLARE command. 
The protocol level cursor creation does not allow specifying options like 
holdable, so the driver can't do this.  The server folks aren't ready for 
a new protocol revision yet, so we're in a little bit of a holding pattern 
for the moment.

> Also how effective is connection multiplexing and processing/reading 
> from multiple result set in parallel?

Only one thread can be fetching data from the backend at a time.  With an 
appropriately set fetchsize, you should hopefully get enough data to spend 
some time processing it instead of waiting for your turn to talk to the 
server.  It all depends on how much processing you do per row.  If you're 
fetching as fast as possible, using multiple threads won't help much.

> BTW, we noticed that all types are returned to the driver as strings and 
> then converted to the specific type upon request (e.g. getInt). Any 
> reason for that?

The problem with binary format is that you might not understand it 
(especially considering user defined types).  So you can't ask for all 
data to be returned as binary.  You must know what the data type to be 
returned is to know if you can handle it as binary.  To get the type 
information prior to fetching the data requires an extra network roundtrip 
(at least for the first execution).  There is an outstanding patch to do 
binary transfer when possible, but it has not been applied yet.

Kris Jurka