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 по дате отправления: