Harshad wrote:
Harshad wrote:
These seem to have paid off; the actual query time
(statement.executeQuery) is pretty fast : about 1 or 2 milliseconds.
But reading from the resultSet using APIs such as getString, getLong,
takes about 250 ms or more!!
Forgot to mention; the query usually (99%) results in just a singe row. The
250ms is consumed in just reading the data from that single row!
Hello Harshad,
I think you'll have a better chance of getting any answers if you
provide more information, for instance;
o data volume; number of rows in table(s)
o the SQL query, and possibly the Java code executing it (a little
later, the query plan might come in handy too)
o database schema (including indexes)
Since you're searching for a string inside a VARCHAR, Derby has to check
all rows in the table. Are you using LIKE in the query?
I'm just guessing here based on the information that is already available.
Is there a way that you can reduce the number of rows that qualify?
Are you seeing the long wait on the first rs.next() ?
What about the subsequent rs.next() calls (if more than one row in the
result)?
There are also some tips here:
http://wiki.apache.org/db-derby/PerformanceDiagnosisTips
Regards,
--
Kristian
