Re: Result Set Cursor Patch

Поиск
Список
Период
Сортировка
От Oliver Jowett
Тема Re: Result Set Cursor Patch
Дата
Msg-id 4092DAE1.5020500@opencloud.com
обсуждение исходный текст
Ответ на Re: Result Set Cursor Patch  (Andy Zeneski <jaz@ofbiz.org>)
Ответы Re: Result Set Cursor Patch
Список 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 по дате отправления:

Предыдущее
От: Andy Zeneski
Дата:
Сообщение: Re: Result Set Cursor Patch
Следующее
От: Andy Zeneski
Дата:
Сообщение: Re: Result Set Cursor Patch