/Performance-Tuning-Problem---tp23652098p23703523.html
Sent from the Apache Derby Users mailing list archive at Nabble.com.
ganest gan...@ced.tuc.gr writes:
Hi all,
In an attempt to investigate the problem I mentioned in my previous post, I
run additional tests and some interesting and weird results were appeared.
May be someone who has good knowledge of Derby's internal operation can give
some explanation. Any
Dean Knut,
Thanks for answer,
The accessed data has higher locality in this query than in the previous
query, and therefore the page cache is used more efficiently.
The previous query used the indexes on big.name and bigref.bigid, which
are ordered differently. So even if the index on
George Anestis gan...@ced.tuc.gr writes:
Another difference is that the previous query had to access the base
table (big) to get the id column, whereas the latest query finds all the
columns it needs in the indexes. You may want to try to add an extra
index to speed up the previous query:
ganest gan...@ced.tuc.gr writes:
select count(*) from big inner join bigref on big.id=bigref.bigid and
big.name like '0ff%';
The result is: 258 and it takes more than 20 seconds to be executed. Using
mysql with the same
configuration the result is produced in milliseconds.
It seems that
ganest gan...@ced.tuc.gr writes:
I am executing using ij tool (java -Dderby.language.maxMemoryPerTable=4096
-Xms256m -Xmx256m -jar $DERBY_HOME/lib/derbyrun.jar ij)
the following query: (I read about derby.language.maxMemoryPerTable in this
mailing list)
select count(*) from big inner join
Hi,
Knut Anders Hatlen wrote:
ganest gan...@ced.tuc.gr writes:
I am executing using ij tool (java -Dderby.language.maxMemoryPerTable=4096
-Xms256m -Xmx256m -jar $DERBY_HOME/lib/derbyrun.jar ij)
the following query: (I read about derby.language.maxMemoryPerTable in this
mailing list)
GANEST.BIGREF ADD CONSTRAINT SQL090517120557051 FOREIGN
KEY (BIGID) REFERENCES GANEST.BIG (ID) ON DELETE NO ACTION ON UPDATE
NO ACTION;
--
View this message in context:
http://www.nabble.com/Performance-Tuning-Problem---tp23652098p23652098.html
Sent from the Apache Derby Users mailing list archive
: Kane, David [mailto:[EMAIL PROTECTED]
Sent: Monday, April 09, 2007 6:27 PM
To: Derby Discussion
Subject: RE: Performance Tuning Problem
Folks,
I think I have answers to all of Army's questions here.
* The request DDL is listed below.
* I included the output in the original posting
Do you have indexes on the important columns of the ASSOCIATION
table? From a quick peek at your query plan, this seems to be
killing you:
Right result set:
Table Scan ResultSet for ASSOCIATION
...
scan information:
Bit set of columns fetched={1, 2}
Kane, David wrote:
Here are the indexes that are being reported on the ASSOCIATION table:
[ snip index display ]
Hate to be a nuisance, but can you post the DDL for the tables in the query? I
find it easier to make sense of the DDL than to parse the index table (maybe
it's just me). You
11 matches
Mail list logo
