>This is really a bad advice. The INDEX ON DELETED() should never be used except for very specific cases. If you index a million record table this way, and try to open this table through a slow network, it might take ages to open the table since rushmore has to load about the whole indextag to find the first non deleted record in the table. This is one of the most nasty pitfalls of the INDEX ON DETELED() tag.

A DELETED() index is not a problem if you include the filter FOR DELETED() when creating the index.

This in fact creates a "sparse" index that only includes the records actually deleted ... vs all records ... and resulting in a very small index indeed (based on the number of records actually deleted ... less than 2k for a handfull of records out of a million records).

>It is way better to avoid situation where large numbers of deleted records occur at the beginning of the table, by either reusing records of by packing the table periodically.

How does one "efficiently" reuse records without resorting to some sort of tag on "DELETED()" ?

Attempting to LOCATE a deleted record in a million record table could result in the entire table being read (without a tag on DELETED()).