Derby DDL is a heavy-weight operation. CREATE/DROP statements invalidate
the in-memory metadata cache, effectively seizing a database-wide lock
on the cache. Applications which perform a lot of DDL at steady-state
will perform badly.
I don't have any better advice than to recommend that you av
It looks like the subquery isn't doing any good. I would have hoped that
the optimizer would be smart enough to join the subquery result to the
primary key on id and then use the resulting row positions to probe into
the heap. But the plan is just joining the subquery result to a full
table sca
The Derby engine has some trivial mxbeans which return simple, static
facts--but nothing which would give you visibility into the progress of
boot-time recovery.
On 2/15/21 10:15 AM, Alex O'Ree wrote:
Upon further investigation, I've seen if there are more than 4 files in the
log directory, mo
Upon further investigation, I've seen if there are more than 4 files in the
log directory, mounting takes significantly longer but i've also seen 20+
files mount instantly. I had the idea of monitoring that directory to see
if the file count changes during the recovery process. It does, but
sometim
I've got a process that creates a bunch of temporary indexes, then does
some work, then drops the indexes. All of these indexes are on different
tables but in the same database. During the drop the indexes phase, i
frequently get dead lock warning messages, each drop index statement seems
to be blo
On 09/02/2021 18:05, Rick Hillegas wrote:
As Bryan points out, please consult the Tuning Guide for information on
how to view your query plan. In any event, your descending index is not
a covering index. That is, it does not contain all of the columns in
your query. That may be what forces the
