Charlie,

>>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.

>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.

You're right. I wasn't carefull enough. It's about the percentage of deleted() records within the optimizable resultset instead of the entire table. In the experiments I did the percentage of deleted records in the entire table was aprox. the same as in the optimizable resultset of the queries.

>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.

Yes, the tablewidth of course is also a variable in determining the constant. A small table will result in a lower value of the constant, a wide table will have a higher value.

>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.

I know... This the exact argument I used a few month back when I fought a heavy battle to convince people that the deleted() tag was almost always unneccesary.


Walter,