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