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