Neil Harvey <[log in to unmask]> wrote:

>Wirt waxed eloquently about the new B-tree features in TurboImage, and I
>can't wait to try these. They'll replace at least four KSAM files that
>our system uses to look up members by name and partial name, and the
>possibilities with numeric fields are exciting.
>
>I presume the B-tree index is maintained automatically, like all
>TurboImage keys/search items, but I would like to know what the
>performance hit will be. I know it can't be as bad as maintaining KSAM
>files in parallel with TurboImage.

I don't know too much about the internal workings of the new B-trees, but I
knew more than I wanted to about the old CM KSAM files, some of which may
be applicable in discussing the performance.  So this e-mail is partly an
answer and partly a question.

I used KSAM files for four reasons:
1.  To obtain the keyed access.
2.  To get sorting on the key.
3.  To get "critical field update", which wasALWAYS present in KSAM.
4.  To get very efficient updating (because records were written to disk
only when the lock was released).

I am presuming that none of these are considerations with NM KSAM except
for 2, but it would be nice to know for sure.

It seems to me that there will be subtle performance hits.  Sorted lists of
names were often done with a KSAM file that used detail set record numbers
to find the record.  Any use of Image B-trees will necessititate a separate
master record for each unique name and could result in many more master
records being created.  Any file on which you want to create a B-tree must
first be given a new automatic master which will add to the overhead on
every new record added.  As they say, "there is no free lunch".  Superdex
avoids this by creating B-trees on details as well, and I believe that
Omnidex operates similarly.  Neither of these require the use of the Posix
name-space either.

Another major performance hit that occurred in CM KSAM was the creation and
deletion of branches, leaves and levels.  I don't think you can have a
B-tree without these processes and they can have some VERY significant
effects on performance.  This was of particular concern if the dataset was
very volatile as one of mine was.  Does anyone know how the B-trees work in
Image and can make a comment about that?  CM KSAM had some esoteric
parameters that could be adjusted so that these kinds of changes
(particularly level creation and deletion) were reduced to a minimum. Does
one have the same considerations in Image B-trees?

P.S.  This was actually written several days ago, but got stuck unnoticed
in my out-box.  The questions are still relevant however.