Re: Result Set Cursor Patch

From: Oliver Jowett <oliver(at)opencloud(dot)com>
To: Andy Zeneski <jaz(at)ofbiz(dot)org>
Cc: pgsql-jdbc(at)postgresql(dot)org
Subject: Re: Result Set Cursor Patch
Date: 2004-04-30 23:01:53
Message-ID: 4092DAE1.5020500@opencloud.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-jdbc by date

  From Date Subject
Next Message Andy Zeneski 2004-05-01 01:10:25 Re: Result Set Cursor Patch
Previous Message Andy Zeneski 2004-04-30 20:51:00 Re: Result Set Cursor Patch