Re: Result Set Cursor Patch - Mailing list pgsql-jdbc

From Oliver Jowett
Subject Re: Result Set Cursor Patch
Date
Msg-id 4092DAE1.5020500@opencloud.com
Whole thread Raw
In response to Re: Result Set Cursor Patch  (Andy Zeneski <jaz@ofbiz.org>)
Responses Re: Result Set Cursor Patch  (Andy Zeneski <jaz@ofbiz.org>)
List pgsql-jdbc
Andy Zeneski wrote:
> Please let me know if there is anything else which would prevent this
> from getting into CVS. Also, if all is good, could you please let me
> know when has been committed so I can update my local tree.

A few comments from looking at the patch..

resultSetSize() does a number of FETCH ABSOLUTEs, throwing away the
results, and then backtracking when it reaches a row that doesn't exist.
A better strategy might be to use MOVE FORWARD ALL and examine the
rowcount in the returned command tag.

fetchAbsolute() and things that end up calling it doesn't seem to
respect the fetchsize, i.e. you always end up with a single-row
resultset in memory. How about executing "MOVE ABSOLUTE n; FETCH FORWARD
fetchsize" instead of just "FETCH ABSOLUTE n"?

How does the performance of iterating backwards through a resultset
compare with the non-cursor case or the forward iteration case? It seems
like with the patch it will end up doing a FETCH ABSOLUTE of a single
row on each iteration. Really fetchAbsolute needs to do either a "MOVE
ABSOLUTE n; FETCH FORWARD fetchsize" or "MOVE ABSOLUTE n; FETCH BACKWARD
fetchsize" depending on the resultset's preferred fetch direction (see
setFetchDirection)

I have a number of code style comments too, let me know if you'd like
the gory details :)

-O

pgsql-jdbc by date:

Previous
From: Andy Zeneski
Date:
Subject: Re: Result Set Cursor Patch
Next
From: Andy Zeneski
Date:
Subject: Re: Result Set Cursor Patch