Jeff Kell <[log in to unmask]> wrote:

<snip>............

>On a larger scale, we should consider HP's stance with respect to
>b-trees.  For example, if a master dataset has a b-tree index, could
>DBGET take advantage of that fact and retrieve the record via the index
>rather than hashing the key and potentially chasing down synonym chains?
>If Image itself took advantage of the b-trees, I would have no problem
>with having b-trees built by default.

I have always been under the impression that one of the major advantages of
hashed keys is that they are more efficient for lookup than b-trees.  A
b-tree ALWAYS forces you to traverse several levels of the tree to reach a
particular record (and the larger the file, the more levels), whereas a
hashed key with a well-chosen capacity and a reasonable amount of free
space will usually reach the desired record with just one read.  Why would
DBGET use the less-efficient b-trees instead?

Furthermore (and I'm really going to display my ignorance here) isn't the
b-tree pointing to the key and not the record number, thereby forcing the
read down the synonym chain anyway?

John D. Alleyn-Day
Alleyn-Day International
408-286-6421   408-286-6474 (Fax)
[log in to unmask]       http://www.Alleyn-Day.com