Fillfactor behavior

It seems that when an index is built, the fillfactor is only approached when the index is unique, or "fairly close" to unique. Otherwise, you can (and frequently do) end up with leaf pages as poorly packed as 40%-60%. oncheck -pT will show you this. The result is I do a lot more index page reads than necessary, and waste a lot of buffer space. Fortunately I've got plenty, at least for now. According to tech support, I'm the second or third person to report this as a bug, and each time, the problem is closed with comments like "working as designed, documentation needs clarification". I think it's pretty weak that an index can't always hit the desired fillfactor at build time. That's one of the main points of building them bottom up - so you never miss. Now, I'm well aware of the desirability of unique indexes, and they become less useful as they become more duplicative, yet they're still a heck of an improvement over a sequential scan most of the time. I'd be interested to hear others opinions on this - If I'm all wet, I'll willingly take my lumps.... -- Greg Moye EDS Corp. - Plano TX