Dragan,

The VFP B+Tree needs to store both the key value and a 4 byte record pointer to the actual record. So for the first index test I posted in the article, using just an integer key, VFP is compressing (4+4) * 10000 = 88000 bytes into 48128 bytes. The 88,000 bytes is a theoretical minimum and would require that every leaf node of the tree is 100% full. VFP7SP1 has lost some of the compression performance because it's splitting full nodes of the tree earlier.

The c(20) index should require (20+4) * 10000 = 240000, but VFP uses only 167936 bytes. Note that I specifically created those test values in a way to reduce their compressibility. VFP7SP1 is using 317952 bytes for the index, which is actually more than the theoretical min.

>I assume the calculus involved there, regarding the number of keys per node, is only approximate - AFAIK, ever since the appearance of .cdx indices, Fox was compressing them, physically storing only the difference between two consecutive values. Mmmm... it's been a long time since I last looked at the structure of a .cdx with a magnifying glass (i.e. hex viewer), could be it's time again.