HP3000-L Archives

October 2008, Week 2

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
"Walter J. Murray" <[log in to unmask]>
Reply To:
Walter J. Murray
Date:
Sun, 12 Oct 2008 13:53:22 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (31 lines)
Thanks to all who responded to my questions about TurboIMAGE B-Tree
indices.  I have been investigating them further, and the feature seems
to work exactly as documented.  There is a good chance I will use them
in a project I am working on currently.

The fact that partial key searches don't work on values like "@SMITH@"
doesn't bother me.  I never expected that they would.

I have encountered only one performance-related surprise.  As I thought
about it, I understood the reason.  I was traversing a super-chain in a
detail data set that was associated with an automatic master.
Occasionally, the mode-5 DBGET would take much longer than I expected to
find the next entry.  Then I realized that the master was linked to a
number of other details, and there were big "gaps" in the key values,
where there were entries in the master (and therefore in the index file)
that had non-empty chains in the other detail data sets, but no
corresponding entries in the detail data set that I was reading.  IMAGE
was doing a lot of work reading in logical sequence through the index
file, and looking up the corresponding entries in the master, only to
find empty chains in the detail of interest.  So it was not a flaw with
IMAGE--just a design consideration to be aware of.

Thanks again to everyone who offered advice.

Walter  

Walter J. Murray

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

ATOM RSS1 RSS2