>Charlie,
>Well the OveadUsingDeletedTag constant is a constant I found with my experiments. Of course it can differ depending on system configuration, tablesize, network, etc. I don't think it is possible to create an excact formula for all circumstances, but I think I will use this as a guideline for future use.
>
>However this constant will never be 1, because rushmore has to process the deleted() tag.
>
>As for the number of records: I don't think it matters a lot. It's about the percentage of deleted records in a table rather than the exact number.
>Walter,

Walter,
No, I don't agree.
Rushmore is effective when it minimizes traffic. If getting all the undeleted pointers is better than getting 20 deleted records, then DelTag helps.
If you have 50% of the records deleted, but there are no deleted records in the recordset specified by the rushmorizable predicate, the DelTag is a burden. VFP had to read the index tag (approximately one half of the entire DelTag portion of the CDX) and return the undeleted pointers, and compare those with the other matches. Every pointer was common to both, so the DelTag has no benefit.

However, if only 2% of the records are deleted, but your Rushmorized expression matches 20,000 records, of which 400 are deleted, and the record width is 1000 bytes, you will retrieve 400K bytes that could have been avoided by reading approximately 120K of DelTag.

So the more you can precisely narrow the resulting record set by an Rushmorizable expression, the less benefit any other additional Rushmorizable expression is--and the more likely it may be a burden.