I'm not sure if I'll get that one sorted for 7.0, but I was planning on
rewriting the JDBC2 version of ResultSet to use cursors, and reducing
the fetch size from the current "All Rows in the result".
The delay isn't in rs.next(), but by the fact that the result is read in
full before returning from the protected ExecSQL() method in Connection.
Maidstone Borough Council
Any views stated are my own, and not those of Maidstone Borough Council.
From: Simon Hardingham [mailto:simon(at)netxtra(dot)net]
Sent: Monday, December 06, 1999 2:35 PM
Subject: [INTERFACES] JDBC - speed with big 'select's
Having just read the results of the post concerning INSERT times, I
I should ask a related question that has been causing me some problems.
I have a servlet which performs a SELECT which returns up to 6000 rows.
These contain just 6 ints and need to be read to perform a specialised
search. The query run's pretty quick, less than a second (although the
to display is much longer), using the psql interface. Therefore I assume
majority of the time the servlet requires is repeated calls to rs.next()
then the requests for each of the fields across the socket connection.
JDBC 2.0 has a setFetchSize() function which looks as though it may
to transfer the results in larger chunks, but I am shooting in the dark
Any suggestions as how I might speed this whole thing up, the INSERT
by using COPY FROM STDIN got me thinking there may be other
Unfortunately I can not perform the selection using a more selective
Many thanks in advance
_/ Simon Hardingham - netXtra Ltd - UK _/
_/ Tel: +44 (0) 1787 319393 Fax: +44 (0) 1787 319394 _/
_/ http://www.netxtra.co.uk simon(at)netxtra(dot)co(dot)uk _/
pgsql-interfaces by date
|Next:||From: jose soares||Date: 1999-12-07 09:47:01|
|Subject: Re: [HACKERS] TRANSACTION "WARNINGS"|
|Previous:||From: Peter Mount||Date: 1999-12-07 07:23:31|
|Subject: RE: [INTERFACES] Problems after creating jdbc driver postgresql.jar 6.5.3|