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
-----BEGIN PGP SIGNED MESSAGE-----
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?

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

iD8DBQFBufuEIv0S4qsbfuQRAlexAJ0Z76uZ7tbf94C7SzTW/teKT/UH3wCfYSk3
16N2j6Q6R6G4IwRY5913ZuE=
=LZ9H
-----END PGP SIGNATURE-----


Mime
View raw message