Re: Where are FillFactors stored in system tables?

Jonathan, thanks for the reply. I was careful to check right after dbimport finished, before anything to cause splitting happens, and also some stand alone tests (load the table, create an index, oncheck -pT to observe the result). 45% is the worst I've seen, 50-65% is more common. An index built bottom up should hit the mark easily all the time in my humble opinion. What you described could very easily happen to an individual index page or pages, but oncheck -pT reports full table / index averages, so even if it did happen to a couple of pages before I checked, it wouldn't skew the average much (I made sure to ignore small tables, i.e. < 100,000 rows, or < thousands of pages...). Unfortunately, tech support put all of its energy into trying to convince me it wasn't a bug, & since it wasn't causing me too much operational grief, I just blew it off, didn't have time to screw with it. Greg Jonathan Leffler wrote: > > }I've seen some (fairly duplicative...) as bad as 45% actual fillfactor > }right after build with fillfactor specified as 90 or 100 in onconfig. > }Yick. > > I'm not an expert on fill-factor, and I've not played with oncheck -pT in a > long time, but... > > If the index fill factor is 90%, then an index node will be split into to > 45% full nodes, and one of those nodes would then get an extra record > inserted, leaving that node at, say, 47% full, while the other would be > stuck at 45%. That seems to be a legitimate consequence of the build > process. > > There are a number of things that could make that an invalid analysis, so > be careful in interpreting this. It may, in particular, depend on how the > index is built. > > Yours, > Jonathan Leffler (johnl@informix.com) #include <disclaimer.h> snip......