I think Rick was suggesting that if you got the right query plan,
using your index as efficiently as possible, then that would be the
best solution? You can find a lot of information about this in

Perhaps your statistics are inaccurate, so Derby is not choosing the
index-based plan? I think there are ways to force Derby to choose that
plan, and there are also ways to ensure that your statistics are

Specifically, see:


On Tue, Feb 9, 2021 at 4:04 AM John English <john.fore...@gmail.com> wrote:
> On 08/02/2021 18:43, Rick Hillegas wrote:
> > I would recommend throwing more memory at your JVM or adding a
> > descending index to system_log.time.
> So, there is already a descending index to system_log.time, and I've
> upped the heap to 2GB. I also added the time taken to service the
> request as an HTML comment at the end of the page.
> The disk is an SSD, and the table contains about 261,000 rows. Accessing
> the first 20 rows ordered by time desc, it takes about 13 seconds, which
> seems a bit excessive to me. Ordering by event also takes about the same
> (12690ms as opposed to 13151ms), so the index doesn't seem to have much
> effect.
> Not sure what to try next... any ideas?
> --
> John English

Reply via email to