The change in timing is spectacular: it now takes about 0.4 seconds
Great news!
I think it would be cool if you could write up a short summary of
your findings and put it on the hints and tips section of the
Derby community wiki.
thanks,
bryan
On 21/12/2012 19:40, Knut Anders Hatlen wrote:
If you run the query with derby.language.logQueryPlan=true and check
derby.log, does the query plan say that log_index is used?
It seems to use it:
Sat Dec 22 18:44:54 IST 2012 Thread[qtp9851452-34,5,main] (XID = 5645972),
(SESSIONID = 18),
Do you have the same results if you exclude details field from your
columns list ?
2012/12/21 John English john.fore...@gmail.com
On 20/12/2012 14:12, Jean-Yves Linet wrote:
Hi,
May you could give more details about the structure of your table.
The table looks like this:
CREATE TABLE
On 21/12/2012 15:20, Jean-Yves Linet wrote:
Do you have the same results if you exclude details field from your columns
list ?
Yes. No significant change.
But: I'm trying it on my development system (127.0.0.1) since I can't play
around the live system, and the time varies by what other
John English john.fore...@gmail.com writes:
On 20/12/2012 14:12, Jean-Yves Linet wrote:
Hi,
May you could give more details about the structure of your table.
The table looks like this:
CREATE TABLE system_log (
id INTEGER GENERATED ALWAYS AS IDENTITY,
time
I have a table representing a logfile, with a timestamp for each entry. There
are currently about 90,000 entries. When I display the log, I normally want to
see the most recent entries first, so the default order is by timestamp
descending. This typically takes about 20-25 seconds. If I want to
Hi,
May you could give more details about the structure of your table.
Anyway the response delay you have seams to be very slow compare with what
I have with Derby.
I always read my resultset as forward only.
Try to make a first request with select count(*) to have the number of rows.
and then a
