>>>
>>>No need to be rude. If you MUST have a useless index, of course, make sure it's as small as possible. That's your argument.
>>>
>>>I know the precisely why the feature exists. It was built to improve a situation that many people believe, which is mostly a myth. If you have one deleted record in 5 million records and your queries are regularly producing small sets of records, only 1 in 5 million times and possibly never, will that deleted index help at all.
>>
>>Please reread my replies. If you find any of them rude, I promise that it wasn't intentional. My ONLY point is that you must compare with identical conditions. If you compare a steam engine with a turbo charged engine running on rocket fuel, of course you will get different results. A binary index is only one eighth in size compared to a normal index, which you don't take into consideration. That's why you compare apples to oranges.
>>
>>Also know that I never delete records, so I never use index tags on deleted(). However, that's not relevant in this argument. 'nuff said.
>
>I disagree. The comparison must be whether you use an index on deleted or not - not whether it is binary or not. If the index is used on a local machine versus over a LAN there is a performance difference again. If you construct your system properly, it is not needed.

And this is why you are totally wrong. Using your analogy, running trains is a bad idea since they use coal and pollute the air. And all airplanes are slow since they use combustion engines and propellers.

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