HP3000-L Archives

February 2001, Week 3

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:
Doug Becker <[log in to unmask]>
Reply To:
Doug Becker <[log in to unmask]>
Date:
Tue, 20 Feb 2001 07:59:41 -0800
Content-Type:
text/plain
Parts/Attachments:
text/plain (28 lines)
Question concerning the following discourse:

Is what Jeff says about NM KSAM correct. 
It was my understanding that NM KSAM was rewritten to be much more efficient than the CM version.
Rumor was that certain not quite gruntled employees from a major Computer Vendor came from the division that wrote the software internals for keyed sequetial files.

True? Irrelevant?

>>> Jeff Woods <[log in to unmask]> 02/18 3:08 PM >>>
Jean Huot wrote:
>Note that EOF/FLMIT = 96%.  Is this a candidate for performance
>bottleneck??  If yes, to what % value should EOF/FLIMIT be??

Short answer:  No, KSAM files do not get slower depending on how full the
file might be.

Not quite as short an answer:
Unlike master sets in Image databases, neither NM nor CM KSAM files use a
hashing algorithm to manage the keys; instead, they use a B-tree
mechanism.  The performance implications are quite a bit different.  One of
those differences is that there is no performance loss for KSAM files based
on how full the file becomes.  Rather, it's on how balanced the B-tree is
and how many levels deep the B-tree becomes.  I don't know any simple way
to measure either of those attributes for the keys in a KSAM file.

--
Jeff Woods

ATOM RSS1 RSS2