Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
BUG: VFP7 SP1 REINDEX no longer removes BLOAT from .CDX
Message
From
04/05/2002 13:55:59
Dragan Nedeljkovich
Now officially retired
Zrenjanin, Serbia
 
General information
Forum:
Visual FoxPro
Category:
Databases,Tables, Views, Indexing and SQL syntax
Miscellaneous
Thread ID:
00652071
Message ID:
00652776
Views:
21
>One of the things that I learned a long time ago was not to use undocumented features to resolve problems. In this case, going all the way back to my first usage of FoxPro (FPD 2.0), I used a combination of a re-ordering of the table based on its intended natural order, combined with a meta-data table to re-build the indexes from scratch to combat both bloat and corruption.
>
>Now jumping ahead to the present day, I must also (based on information that both you and Christof Lange have provided) jump to the conclusion that the change in the behavior of the command is intentional and intended to combat these problems. If so, it begs the question of why we're wasting so much bandwidth on the subject.

I think people may be a little change-shy here (including the originator of this thread). CDX bloat was a bad thing back then in 1.0x and 2.0 days, and still is. Observing some sort of bloat today surely doesn't make you comfortable - words "resurrected bug" come to mind.

OTOH, I think DavidF has given us a reasonable explanation, which probably doesn't sound too intuitive: balanced tree. From what I know about the b-tree theory, when repopulating a tree, the engine starts with a certain percentage of free space in each of the nodes, so the subsequent inserts don't cause too many page splits in the future. Chances are (calculated) that a good share of new keys will be quite evenly distributed all over this allocated space, and that the number of page splits will stay really low for quite a while. VFP does that (I'm assuming here :), SQL server does it, even the RMS on old PDP was doing it 15 years ago.

Of course, a .cdx with this additional space may be bigger than it was before rebuilding, but then this may as well mean improved speed - not only when adding new records (fewer blocks need to be written, and the addition of the new block doesn't happen so often), but also when accessing records (a balanced tree should also mean the number of hops to find a node is uniform across the whole index).

This actually gets me worried. I start sounding like a professor again :).

back to same old

the first online autobiography, unfinished by design
What, me reckless? I'm full of recks!
Balkans, eh? Count them.
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform