>SNIP
>>>
>>>Given especially #2 above I believe that any .CDX that regularly has lots of INSERTION activity AND a TAG primarily used in the application that has a wide range in those INSERTIONS will benefit from regular reindexing. Such reindexing will result in a smaller .CDX with the need for fewer reads necessary to access all pertinent index records.
>>
>>You're addressing the speed issue now. I guess that tests could verify/falsify your hypothesis. My hypothesis is that there will be no significant gain in speed.
>
>That may well be the case with today's hardware having super-fast average access times and large on-board cache. But I would still opt for smaller and more 'consolidate' being faster, even if now it is limited more to the theoretical than the practical. I do think that this would be quite difficult to benchmark accurately with today's premium hardware, though the point might be better confirmed using, say a PII 90mhz and an old 1gig HD.
>>
>>And how about the other IMO false perception, correctness?
>
>If it's faster it is more "correct" as I see it. If its smaller it's more "correct" as I see it.
>So I would say that corectness is TRUE, not false.

Okay, let me explain more clearly what I mean with 'correctness'. It's another word for 'correct indexes'. If you offer superusers the option to reindex, then these superusers will regularly fear that indexes may become incorrect, thus causing incorrect retrieval of data. For example, they may assume that certain records are no longer displayed due to incorrect indexes and they think that a reindex will let the missing record reappear. I think this is too often a false perception and a reindex gives false hope. If an incorrect index is really at stake, then a call to the developer/helpdesk is a better reaction to the situation than a reindex.

>cheers
>
>>
>>>cheers
>>>
>>>>
>>>>
>>>SNIP