Thomas,

So far I did not base my conclusions on tests, but on the underlying technique. This was proven to be valid in previous versions and I don't see any signs that this has changed in VFP9.

Again, the index on deleted() alway has a low selectivity and no matter the argument low selectiviy means a useless index in most cases.

I'll back up my theory with some real time examples later.

Walter,




>Hi Walter,
>
>while I agree that in the previous versions there are usually more use cases/real live scenarios in which it is better not to use indices on deleted(), I'ld reserve judgement till the final product is in my hands. Perhaps the new constructs like select in (select...) might actually benefit.
>
>>Unfortunately, the binary index is a miss. Though much smaller it really does not adress the problem: Low selectivity and therefore it does not change much to the story. If the deleted() tag is not going to weed out (many) deleted() records it use is useless.
>
>Binary index lowers the threshold for an index on deleted() to be useful - and in WAN situations this might apply. I view this mostly as a bottleneck problem, and the size of the amount to pass the bottlenack has been reduced. No discussion about situations where you can query using a PK[returning a single record], but on queries passing nontrivial sets it probably mostly boils down to the difference of
>(size(all_indices) + size("rushmored" Recordset)) - size("nonrushmored" Recordset)
>
>I am intrigued by the mention in the docs, that any index using deleted or !deleted() migth be used by rushmore. Perhaps size(binary_not_deleted) <> size(binary_deleted) traveling the wire is significantly different. But perhaps I misread - and for that kind of stuff the beta is the wrong version to test.
>
>my 0.02 EUR
>
>thomas