Thread: Cursor returned from procedure ignores setFetchSize() on CallableStatement
Cursor returned from procedure ignores setFetchSize() on CallableStatement
From
"Brian G. Huber"
Date:
Hello all -
I need to return large result sets and therefore need a cursor with a small
fetch size (to avoid caching the entire query at once). However, it appears
that when a cursor is returned from a callable statement setFetchSize is
ignored.
I set up a query that crashes with outofMemoryError if entire query is
cached. I am able to sucsessfully use a Statement and setFetchSize() to
avoid the crash. However, when I put the code in a procedure, the
outofMEmoryError throws before I even try to access the result set,
indicating that the entire query is caching. This is true with or without
calling setFetchSize on the ResultSet in addition to the CallableStatement.
Is this a bug or am I doing something wrong? Any comments greatly
appreciated. Thanks
Client
Code--------------------------------------------------------------------
cn.setAutoCommit(false);
CallableStatement proc = cn.prepareCall("{ ? = call reffunc2('cursor1') }");
proc.setFetchSize(100);
proc.registerOutParameter(1, Types.OTHER);
proc.execute();
rds = (ResultSet) proc.getObject(1);
rds.setFetchSize(100);
while (rds.next()){
...
}
Function--------------------------------------------------------------------
CREATE OR REPLACE FUNCTION public.reffunc2(refcursor) RETURNS refcursor AS '
BEGIN
OPEN $1 FOR SELECT ...<Large Query>...;
RETURN $1;
END;
' LANGUAGE 'plpgsql' VOLATILE
I need to return large result sets and therefore need a cursor with a small
fetch size (to avoid caching the entire query at once). However, it appears
that when a cursor is returned from a callable statement setFetchSize is
ignored.
I set up a query that crashes with outofMemoryError if entire query is
cached. I am able to sucsessfully use a Statement and setFetchSize() to
avoid the crash. However, when I put the code in a procedure, the
outofMEmoryError throws before I even try to access the result set,
indicating that the entire query is caching. This is true with or without
calling setFetchSize on the ResultSet in addition to the CallableStatement.
Is this a bug or am I doing something wrong? Any comments greatly
appreciated. Thanks
Client
Code--------------------------------------------------------------------
cn.setAutoCommit(false);
CallableStatement proc = cn.prepareCall("{ ? = call reffunc2('cursor1') }");
proc.setFetchSize(100);
proc.registerOutParameter(1, Types.OTHER);
proc.execute();
rds = (ResultSet) proc.getObject(1);
rds.setFetchSize(100);
while (rds.next()){
...
}
Function--------------------------------------------------------------------
CREATE OR REPLACE FUNCTION public.reffunc2(refcursor) RETURNS refcursor AS '
BEGIN
OPEN $1 FOR SELECT ...<Large Query>...;
RETURN $1;
END;
' LANGUAGE 'plpgsql' VOLATILE
On Tue, 8 Jun 2004, Brian G. Huber wrote: > I need to return large result sets and therefore need a cursor with a small > fetch size (to avoid caching the entire query at once). However, it appears > that when a cursor is returned from a callable statement setFetchSize is > ignored. > > Is this a bug or am I doing something wrong? Any comments greatly > appreciated. Thanks > Yes, currently refcursor based ResultSets fetch all rows at once. I would say that this is a missing feature rather than a bug, but in any case it's something the driver can't do right now. I'll put this on my todo list, but it's not going at the top. I was under the impression that refcursor returning functions would fade with the advent of easier set returning functions. Have you considered using them instead? The advantage of returning refcursor seems to me that you don't need to create a pseudo type for the return value, or deal with specifying record types in the query. Are there other advantages I'm missing? Kris Jurka
Kris Jurka <books@ejurka.com> writes: > I was under the impression that refcursor returning functions would fade > with the advent of easier set returning functions. Have you considered > using them instead? The advantage of returning refcursor seems to me that > you don't need to create a pseudo type for the return value, or deal with > specifying record types in the query. Are there other advantages I'm > missing? Portability. Efficiency. Nic