>It still can be useful. It is likely to not speed up selects on tables with only few deleted records, even with the new BINARY indices. It's a trade off between the index data, which needs to be read vs the number of deleted() records loaded and discarded anyway.
>
>But you can also have filtered indexes with DELETED(), that are used by rushmore. There's a chapter "Indexes Based on Deleted Records" about this. So even an index on "A" for Deleted() may work better than a binary index in situations with few deleted records, but you need to have a maintainance routine rebuilding the indexes, as filtered index have some bloating effect and don't shrink to fit, if you pack the tables and recycle records with recall and blank.
>
>All in all it's still an issue of try on error, what's best. If you often do maintainance, pack and reindex, it's likely the partial optimizations rushmore does without the deleted() index are even faster or at least sufficient, as you normally have other filters on a table limiting the result much more than the deleted flag. But those indexes can be helpful to speed up aggregations like Min(), Max() and Count().
>
>So it's still "it depends". But I'd not generally index on deleted().

Thanks