-----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-----
