db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Knut Anders Hatlen <Knut.Hat...@Sun.COM>
Subject Re: simpler api to the Derby store
Date Tue, 15 Jul 2008 14:14:59 GMT
Mike Matrigali <mikem_app@sbcglobal.net> 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.

-- 
Knut Anders

Mime
View raw message