>>>>If you need an index on a logical field or on deleted(), make sure to add the Binary keyword when you create it. That will make the index much smaller, meaning much faster.
>>>
>>>Not faster than not having the index at all, especially when other filters have already identified the records.
>>
>>When binary came out, we measured perf with traditional, binary and no index on deleted() on sizable data sets of a real application, as I already had a test harness based on QueryPerf in place. We weighed the results of the different data sets to the largest, as runtime duration was rising more than linear.
>>
>>Binary was the best compromize, leading to smallest total time and no really bad performance in single measurements -
>>was never the worst / an outlier. IIRC we added a more than a dozen binary indices to tables where we had previously deleted a traditional index on deleted() - after running perf tests, total table count > 300.
>
>I've done a lot of removal of the deleted index and only saw performance gains - except where someone was doing an unfiltered count with set deleted on, which became - "count for not deleted()". There are always explanations of why the deleted index had a positive effect, but these reasons were not proof.

Are in all these cases, were normal index tags used, or binary index tags? If binary index tags were not used, you really compare apples to oranges. The difference is huge, to say the least. Others have performed similar tests WITH binary index tags on Deleted(), and their conclusion was that binary index tags in most cases resulted in huge speed gains.


>>
>>YMMV
>>>
>>>>
>>>>>The more it makes sense for me to get rid of it. Thank you.
>>>>>
>>>>>>Any index on a binary value will generally not be very effective. I've heard some people say that an index on DELETED() is effective if you have a high number of deleted records, but never tested this myself.
>>>>>>
>>>>>>