Jos / Jim,

The original statement of DavidF was that "bloat is something that affects performance" and that therefore "routine reindexing is prudent [...]". I have serious doubts about this position, well okay, under 'normal' circumstances. By the way, let not this thread become another discussion about bloat itself please. For that's not the issue I'm interested in, for now. Although bloat certainly is an issue if very large cdx-files are about to fill up an entire disk, in my case I'm only interested in the performance (=speed) and 'correctness' issues of (re)indexing.
My view is: Under normal circumstances, REINDEX, or its drastic equivalent, will NOT improve performance. Therefore there's no need to advice superusers to regularly start the menu-option that will reindex all tables. The only time such an advice is ok, is when the SUPERuser has the feeling that an index has become outdated or corrupt. But even then it's often an even better advice to make a call to the helpdesk or developer.
In other words, a reindex menu-option gives the user a false feeling of control over speed and correctness. Furthermore, while the superuser reindexes, other users cannot use the application. Sometimes that'll take minutes, in other applications it may take an hour or so. Precious time ... for nothing but false expectations.

Agree? Or disagree?


>My view is as follows:
>
>That VFP7SP1 did not eliminate the bloat caused by record insertions likely resulted in at best marginal improvement of performance regardless of the frequency of REINDEX. Unless an application made 'regular' use of the DELETE TAG (probably infrequent in production aplications) in which case it should be helpful.
>
>That VFP8, at least in its beta incarnations to date, does return to elimination of "record insertion bloat" suggests that what was observed in VFP7SP1 was an unintended consequence of something done (or left undone) in the VFP7SP1 release.
>
>Assuming that VFP8 (whatever it may be called < s >) retains the change observed in the beta, I'd say that regularly REINDEXing is still to be recommended, with extra considerations as regards applications running VFP7SP1.
>
>Some prefer to simply use the REINDEX command while others insist on the combination of DELETE TAG ALL followed by INDEX ON... commands. I think the recommendation applies in either case.
>
>cheers, and Merry Christmas.
>
>
>>Hi Al,
>>
>>I've read the threads you're (I think) referring to. The 'discussion' I'm now seeking is whether or not users should be instructed to 'reindex' regularly, for performance reasons. That was not the core of the discussions in the threads I've read. If it was in the thread you're referring to, then I'd appreciate a link.
>>
>>I wonder whether reindex gives better 'balanced tree structures' and 'physical disk clusters'. Who knows?
>>
>>>>Hi David,
>>>>
>>>>In an old thread you say:
>>>>
>>>>"CDX bloat is something that affects performance. Routine reindexing is prudent for tables that undergo lots of adds and deletes."
>>>>
>>>>Are you suggesting that a reindexing routine (or a 'delete tag all' followed by various 'index on' commands) should be part of any application that handles tables that have a lot of records added and deleted?
>>>>
>>>>My hunch is that there's no gain at all. I'm talking now about vfp7sp1. Addition of records will not over-inflate the cdx. And deletion of records will neither inflate nor shrink the cdx. Purging the deleted records with PACK also implies a REINDEX.
>>>
>>>IIRC this was discussed at length some time ago and yes, .CDX size doesn't vary as much as it used to. However, theoretically a reindex might let VFP better balance any tree structure in the index, and/or arrange physical disk clusters for higher performance. I don't know if VFP actually does any of this.

Groet,
Peter de Valença

Constructive frustration is the breeding ground of genius.
If there’s no willingness to moderate for the sake of good debate, then I have no willingness to debate at all.
Let's develop superb standards that will end the holy wars.
"There are three types of people: Alphas and Betas", said the beta decisively.
If you find this message rude or offensive or stupid, please take a step away from the keyboard and try to think calmly about an eventual a possible alternative explanation of my message.