Leon writes:
 
>> Some people (among which our adager friends & hp) say taking a prime for the
capacity
>> is a good rule, but I was a bit more stubborn than that and wrote a small
programme
 
Stan writes:
 
>No, Adager people have spent a lot of time over the years trying to
>debunk the "primes are better" myth.  I think there might even be a paper
>on that (by Fred White) available from Adager.  I'd check their web site
>at: http://www.adager.com
 
>> I'll dig up the source tomorrow and let know where you can get it.
>> It's cobol and has been tested on datasets up to 1 million
>> records.
 
We use the program DBSIZER from the INTEREX Contributed Software Library which
shows the number of secondaries for a range of capacities on a master set. It is
written in FORTRAN and was contributed by Tony Pierce from the Boeing Company.
The best capacities for our master sets are always non-prime numbers. DBSIZER
handles capacities up to 1,440,000 by using extra data segments.
 
>Sounds interesting.
 
As an example, a master set with a prime capacity of 307 and 229 entries has 68
synonyms. The minimum synonyms is 65 at a prime capacity of 263 and the maximum
synonyms is 93 at a prime capacity of 257 for the range 229 to 307. The minimum
synonyms is 56 at a capacity of 297 and the maximum synonyms is 137 at a
capacity of 256 for the range 229 to 307. For the range 307 to 320 the minimum
synonyms is 50 at a capacity of 314 and the maximum synonyms is 90 at a capacity
of 320.
The best capacity for the first range is an odd number and the best capacity in
the second range is an even number. Prime numbers give average synonym counts
avoiding extreme values.
 
>> Another approach is optimizing the key. A J? always better than an X?
 
>No key type is "always" better than any (or some) other key type.
 
>> The first 4 positions in a x? decide mainly on the hashing,
 
>Positions = bytes?
 
>> Frankly I thought no-one cared anymore for this sort of tuning stuff. Buy
more
>> Iron(by which he means hardware) my manager always says when we bring up the
tuning subject.
 
Throughput is what managers are concerned about. This involves many variables
being in balance on a system. Database performance is an important factor along
with the performance of the operating system.
 
>Ah, the problem with non-technical managers :)
>Of course, throwing hardware at a database that has problems due to
>hashing oddities/data-layout/etc. generally won't help anyone other than
>the person who sells you the hardware.
 
Throwing hardware at the operating system helps when upgrading from one release
to the next. MPE/iX 4.0 to 5.0 needs lots of extra memory to maintain throughput
at the same level.
 
>--
>Stan Sieler                                          [log in to unmask]
>                                     http://www.allegro.com/sieler.html
 
Ken Nutsford
Timeshare Systems Ltd
(Where MPE/V is a pre-loved operating system and UNIX is a four letter Greek
word.)
<[log in to unmask]>