db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: Derby performance and data volume
Date Wed, 22 Sep 2004 16:58:04 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

~From first implementation derby always just used the JVM directly as
it's execution engine, so I don't know if this approach would be faster.
It would require a lot of work to create a derby specific execution
language and an intermediate derby specific execution code.

For queries with more than one table I believe most of the "compilation"
time is actually looking a different execution plans to pick the best
one.  I don't see an easy way to avoid this - I guess the absolute
number of plans looked at could be made much lower on first execution
and then when it was found that query was being executed a lot, it could
be recompiled spending more time looking for better plan.

To give some background I believe that queries with small number of
tables probably work pretty well, in the past that has been where most
of the pre-derby usage has been - and thus where most of the engineering
work has been.  There may be room for improvement in optimizing very
complicated queries, this just was not what most users pre-derby were
interested in.



Steen Jansdal wrote:

| Mike Matrigali wrote:
|
|  >
|
|> <...snip...>
|>
|>
|> A couple of areas to watch for:
|>
|> 1) optimization/comiplation of queries in derby is relatively costly,
|> most work to this point has been in making execution of already compiled
|> queries perform better.  The assumption has been that it is ok to take
|> time optimizing/compiling the query, and then the result will be cached
|> and reexecution of the query the next time will pay no
|> optimization/compilation cost.
|>
|  > <...snip...>
|
| I have thought a lot of this approach and have been wondering if it was
| possible to implement a hotspot concept like the JVM. The first couple
| of times a query is executed it is executed by a "normal" executor and
| only when the engine decides that this is a hotspot query a compilation
| takes place. Unfortunately I don't have the knowledge of the engine yet
| to try this out, but maybe other can step in.
|
| Steen
|
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBUa8aEpeslyHqPs0RAo4HAJ4lXy5l4yM0+kjWazh6iGbvetma6ACeIOQ3
fnHFABv6rceaFjBFwSHH9ZI=
=rLB/
-----END PGP SIGNATURE-----

Mime
View raw message