<<Agreed: disc is cheap, and time is money. But doesn't too much
slack space hurt performance? Or did I misunderstand what I read?>>


Depends on what you understood ;-)

I guess there are cases where having "gross overcapacity" in a data set would
hurt performance. Say you had a set with a million records, and deleted all
but ten thousand of them, and the existing records were distributed over the
entire file. I'd think that having to retrieve records from a space 100 times
larger than needed would definitely reduce performance. Conversely, expanding
an existing detail set by a factor of 100 should have no impact, since the
data is still located in the same amount of space, and VSM would never to
spend time paging in the unused 90% of the file. Making a master set orders
of magnitude too large would not be good, as it would end with the data
scattered all over the file by the hash algorithm. But then, master records
tend to be, proportionally, multiples or orders of magnitude smaller than
detail-set records, so a page will hold a lot of them, mitigating the problem
to some extent.

Speaking from a totally fact-free position, I'd WAG that the slope of the
"performance drop-off curve" is *much* steeper on the "not enough space" side
of the baby-bear point than that on the "too much space" side.

Steve