>>>>Rushmore optimizes an INDEX ... FOR lExpression command if lExpression is an optimizable expression. For best performance, use an optimizable expression in the FOR clause.
>>>
>>>Jess, this means that the expression in the FOR clause has to itself be optimizable. That means there must be another index on that expression.
>>
>>So it clearly explains that an INDEX...FOR (Filtered Index) can be optimizable if the expression is optimizable.
>
>But this a meaningless point. The FIltered index will NOT be used in any optimization, only the index that made the filtered clause optimizable. IOW, for the example you gave above....
>
>INDEX ON code TAG code FOR code = 'I'
>
>is only optimizable if you also have an index
>
>INDEX ON Code TAG Whatever
>
>So, this really means that the first index is not usable at all. Any expression will not use the first (filtered) index, but the second, non-filtered one.

The second and third statement benefits on what the filtered index has done. Because the data has been intact. It's a way way faster approach:

SET ORDER TO code
SUM FOR date >= {12/19/1999} AND etc.

is faster than

SUM FOR code = 'I' AND date >= {12/19/199} AND etc.

>

>
>>CALCU SUM blah..blah.. && not optimizable anymore
>>SCAN FOR.... && not optimizable anymore