-----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-----
