Knut Anders Hatlen wrote:
Mike Matrigali <[EMAIL PROTECTED]> writes:
I do wonder if within this scope derby could do a better job of
addressing the application paradigm of only needing single keyed
access to a row of the form (short key, short data). By being embedded
derby already presents a better solution for a java application than
a lot of databases. So issues are:
1) can we improve the jdbc implementation to make using it for a
compiled plan close to as efficient as a non standard, store specific
interface?
Not an answer to your question, but I performed a small experiment to
get a feel of how large the overhead imposed by the SQL and JDBC layers
was for these simple queries. I used the single-record select test in
org.apache.derbyTesting.perf.clients.Runner, which just performs primary
key lookups and fetches about 100 bytes of data. When I accessed the
same table and index directly through the store API (using same
isolation level, holdability etc), I got about 15% more accesses per
unit of time than when I accessed them through JDBC.
The test was basically just a loop performing these operations:
* Traversing the B-tree (three hops, I think) with
TransactionController.openCompiledScan()
ScanController.fetchNext()
* One hop from the B-tree to the heap with
TransactionController.openCompiledConglomerate()
ConglomerateController.fetch()
* TransactionController.commit()
I'm not sure how small an overhead in JDBC/SQL we can hope for, 15% is
perhaps not too bad. If we implement some of the suggested improvements
in the store without improving the top layers, the relative overhead of
those layers will increase, though. In such a scenario, it may become
more attractive to find a way to bypass those layers, unless we manage
to reduce the extra cost.
Thanks for the experiment. Those numbers seem really good to me. To me
at least from the performance point of view it would not seem worth
adding another interface. I would not be surprised if there are things
that could be done to even do a little better on the 15% overhead that
would then help both overall derby and the simple interface users
applications. And of course it means you are unlimited in the
complexity of queries you may want to run, using a well known standard
interface.
This of course does not solve the code size issue if it is an issue for
a particular device.
As to simplicity, it does seem like at the cost of a single extra method
call you can turn jdbc into a set/get interface against a single keyed
table if that is all you want.
