db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@debrunners.com>
Subject Re: BackingStoreHashtable
Date Fri, 10 Dec 2004 19:39:48 GMT
Hash: SHA1

Mike Matrigali wrote:

> and some more history, originally when the overflow portion of
> BackingStoreHashTable was considered more of an error path a suggested
> implementation was to just use the existing derby temporary btree table
> implementation to implement the overflow portion of the class.  The
> key would be the hash key, and the data the rest of row of the result set.
> benefits are it would be easy to implement, be a lot less code to
> maintain, and reuse existing technology.  It already has full support
> for bounded access to duplicates.
> Access performance would likely be worse than a hash table assuming
> single I/O access to a given key.  Searches would have to traverse the
> in memory cached index nodes.

I think the potential performance of each should be careful considered
before a new on-disk structure is created. It seems like the btree would
work well, but it's not clear to me what Jack is proposing yet.

Jack, what happens when the in-memory hash table overflows to disk?
Is it a complete switch to the disk version, or is the in-memory table
in front of the disk version with a sub-set of the data?

Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


View raw message