Thanks Charlie.

Looking forward to the article (or precis thereof).

Cheers,

Jim N

>Walter, Jim, et.al.
>One of the key points to consider here is the number of records that match the Rushmorizable expression. This will determine the whether the DelTag is expensive or economical. If the RushExp matches only 4 records, and the table is large, the Deltag is undesirable. If the expression matches 10,000 records, and 500 are deleted, then it will help. If only 2 are deleted, it's a waste. Which is greater: the number of bytes of deleted records we read, but discard, or the number of bytes of the undeleted portion of the DelTag--that is the question.
>
>I don't know what the formula should be, but one of the variables should be the number of records that match and the percentage of those matching records which are deleted. However, Walter, I agree with all of your general conclusions concerning this issue.
>
>I finished an article for our users group a week ago, but the editor hasn't gotten the newletter out yet. When he is done, I hope to inform those involved in these threads as to it's URL.
>
>>Jim,
>>
>>I Tested the DELETED() tag behaviour for FPW 2.6 in the following circumstances.
>>
>>- On a NT-server machine, No other Fox versions installed.
>>- Over a 10 mb lan network (not used by other means than this experiment).
>>- With a SQL SELECT SUM() FROM ... WHERE Expression (Expression is rushmore optimizable)
>>- With a SQL SELECT *, .T. FROM ... WHERE Expression (Expression is rushmore optimizable)
>>- I used two identical tables: one with the index on deleted() (TAGGED) the other not (NONTAGGED).
>>- The tables were not fragmented, the indexes balanced with reindex.
>>- The tables both are approx 17MB, 152.000 records.
>>- I did test the performance with 5%, 10% and 20% deleted records.
>>
>>When the queries run for the first time the difference between performance between the deleted()
>>tagged and the non tagged table where as follows: The TAGGED table was a little slower when the amount of records dropped below the 10%
>>and was a bit faster when the amount of records was above the 10%. This may sound reasonable because the extra deleted() tag is dragged over the network while it's benefit is virtually none when there are just a few deleted records.
>>
>>For the record: All the queries run in approx 11 seconds and the variation was about a few tenths of a second.
>>
>>
>>When the index was alread on the client, the TAGGED queries run almost alway's according the following formula.
>>- Perforance gain in seconds = Totaltime NONTAGGED query * deleterecords% * OverheadUsingDeletedTag(approx .60)
>>
>>Though I know that this won't prove anything about the deleted() tag in all cirumstances, but It gives me the impression that not muchs
>>has changed since the FP(W) 2.x days
>>
>>Walter,