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.
Peter
--
Peter Mount
Enterprise Support
Maidstone Borough Council
Any views stated are my own, and not those of Maidstone Borough Council.
-----Original Message-----
From: Simon Hardingham [mailto:simon@netxtra.net]
Sent: Monday, December 06, 1999 2:35 PM
To: pgsql-interfaces@postgreSQL.org
Subject: [INTERFACES] JDBC - speed with big 'select's
Hi,
Having just read the results of the post concerning INSERT times, I
thought
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
time
to display is much longer), using the psql interface. Therefore I assume
the
majority of the time the servlet requires is repeated calls to rs.next()
and
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
allow me
to transfer the results in larger chunks, but I am shooting in the dark
really.
Any suggestions as how I might speed this whole thing up, the INSERT
trick
by using COPY FROM STDIN got me thinking there may be other
alternatives.
Unfortunately I can not perform the selection using a more selective
SELECT
statement.
Many thanks in advance
Simon
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
_/ Simon Hardingham - netXtra Ltd - UK _/
_/ Tel: +44 (0) 1787 319393 Fax: +44 (0) 1787 319394 _/
_/ http://www.netxtra.co.uk simon@netxtra.co.uk _/
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
************
