db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anders Morken <ander...@stud.ntnu.no>
Subject Re: Releasing latches when waiting for locks. When and why?
Date Mon, 20 Nov 2006 22:26:22 GMT
Mike Matrigali:
> by single row update do you mean (obviously not exact syntax):
> update x = y where key = z

This one, yeah. ~100-byte rows, INTEGER primary keys, we update the
filler only. UPDATE thetable SET filler = <foo> WHERE key = <random number>;

> In the cursor case derby maintains an "internal" lock on the btree page
> so that it can optimize scanning.  This lock allows the scan to maintain
> it's position without extra overhead on each next on the page.

We haven't considered the impact of cursors, maybe we should take a look
at that. Thanks for the tip. =)

> Do you have something to compare these numbers to.  Maybe compared to 
> the overall cost of Derby inserting a single row (not comitting), on the 
> same machine.  Basically would be interested in what is the current
> locking overhead in cpu cost per some standard statement/xact.  I think
> when I looked at this awhile back locking/latching together was 
> somewhere around 5% of
> a TPC/B like xact.  Given that, making locking 0 would only give a 5%
> improvement, so never was that motivated to look at latching.  But
> maybe other parts of the system/JVM have raised the ratio.

Knut Anders Hatlen has gathered a lot of interesting figures in
http://wiki.apache.org/db-derby/Derby1961ResourceUsage2 - well worth a
look and a bit of pondering. =)

The major benefit of reworking the lock manager is scalability - right
now it's pretty much single threaded, which is fine for a lot of the
scenarios Derby was written to perform in. However, for "benchmark
compliance" in a world of multicore desktops and servers, it may be
beneficial to work on Derby's scalability. 

To maintain Derby's small footprint while expanding it to handle bigger
iron is one of the challenges here, and we don't want Derby to become
big fat O-hm-cle, do we? =)

> What java profiler do you use?  Do you like it for working on Derby?

NetBeans' profiler, freely available from http://www.netbeans.org/ as an
add-on to the (also freely available) IDE.

> >I dunno if our report would be of any interest to you guys, but it's not
> >finished yet, and I'm not sure if it appropriate to post it just yet.
> I would be very interested in seeing the report.

At least we'll have to work a bit more on it before presenting it even
as a draft. But Knut Anders has measured many of the same things we've
measured and reported the juicy bits on the list and in the Wiki, so
you're not missing out on terribly much. =)

Anders Morken

My opinions may have changed, but not the fact that I am right!

View raw message