>>....
>>>In the help under "Indexes Based on Deleted Records"
>>
>>But read the Note for the Min/Max - makes me wonder if the optimization is only adding the deleted flag to index key as well, eliminating the round trip to the table for each record to check deleted() status if no separate deleted() binary index is available to prune the record #s.
>>So there definately were optimizations in that, but if all touched the Rushmore Engine is not totally clear to me (too lazy to create more test code...)

>I've just made some tests, thanks to Gregory update on this, and found that the optimization cases described in the help are rigorously true, and when using aggregated functions, the only optimization used for DELETED() or with SET DELETED ON is when making indexes that adds "...FOR DELETED()", but simple indexes on just "DELETED()" are not used :-(
>But this index is not used only in this cases, in all others it is used anyway, so seems that adding "FOR NOT DELETED()" in every index is the most optimized approach.
>Too many years believing that "FOR" indexes where BAD and not optimizable :-(

In Help under "Indexing Effectively for Rushmore..." it is still described. Even more a mystery for me is the reason for "isblank and empty are not optimizable" further down. Could you put your test code to vfpX, so perhaps others can enhance for such corners and added new capabilities ? Also for users of previous versions, as it is probably not totally clear what is optimized in which version ;-)

//upd: did small test with index on empty(), which resulted according to sys3054 to optimize a simple query - both normal and binary. Binary was what I remembered setting up time ago on empty for speed benefit - and this clearly runs against doc (my version vfpX, but from 2011 - do not use it often)

testcode piping results into txt or dbf file with rough description should be good enough, nothing fancy

thx

thomas