My 2 Cents, Split load, and merge load are set to 60/40 by default for KEYONLY dynamic files. That is to say when 60% of the group is filled with keys, it can split. (Note that actual condition on when the spilt occurs takes more things into consideration). So splitting of groups will create more groups (and more frames that can have unused space).
Yet for performance, you must consider the direct reads and writes. The more items per group the higher the potential for overflow groups. (And yes, dynamic file have overflow groups) In the case where we use the default 60/40 spilt, we have more items in a group then can fit in the first block of the group. (unless the ids of the item are much larger then the data in the item) Thus the majority of the data portion of the item is in another frame. You can minimize this by either lowering the split/merge factor for the KEYONLY items, or switch to the KEYDATA method. Note this will cause an interesting issue. Your selects may take longer. A Dynamic file with an improper split/merge loads will experience the same issue as a poorly sized static file. 'The simple select will run faster, but reads and writes will take longer.' This is due to the amount of reads required to gather all of the ids. If the ids are in fewer groups, the system will read through them quicker then if they were spread out in a properly sized file. It is better to properly size the file then add indexes then to have an improperly sized file. Note I can ramble on for hours more on the topic, but will stop it here, and see if anyone actually got this far in my message. As for the suggestion to change the hash type, a good way to check is to copy some items (I usually do 100) into a test file, and perform HASH.TEST twice on them, and pick the type that has the lesser amount of Empty Groups. Michael Rajkowski Senior Programmer/Analyst Bolo Systems Inc. (720) 212 - 0691 ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
