David,

Can you demonstrate the benefits of deleted() tag using NOFILTER
in SQL SELECT command? I always work with real cursors on disk,
not with filtered virtual ones.

There is a very big bug (for me) in vfp grid control:
SET FILTER

and invoking grid control for this filtered table causes grid
to hang because it will NOT use rushmore.
I have an idea that adding a tag on DELETED() allows full
rusmoe optimization and can speed up grid control?
Have anobody tested it?

I tried to replace set filter + grid with local view, but
local view always reads the whole table to disk and this also
causes computer not work for large tables.
Maybe adding index on deleted()
sometimes causes local view to put only filter.
Will grid control on such view use rusmore?

Currently I use set key command. But because the query expression
can be virtually any, this leads to implementing oracle or rusmore in
foxpro.

I cannot make query return small subset of records as in client-server
development: search expression can return rows in range 0 ... 200000


>
>See my post I just made to Andrus. The test table has NO deleted records. It doesn't have to have deleted records to see how the tag help. The number of deleted records will have some impact on the number of rows returned, but that's not nearly as significant as the disk I/O difference between reading the B+Tree out of the cdx vs reading table records.
>
>>to ALL.
>>
>>The problem of an index on DELETED() is that it has a very low selectivity. If the optimizer has to return records which are not deleted, it returns about 95% of the entire table.
>>
>>If you look on other sort of indexes, like articleno in an invoice table, the selectivity could be smaller than 0.1 % (as you have more than a few articles) of the entire table. Now this kind of indexes gives rushmore really a chance to speed up things because it not has to search sequently in the other 99.9 % of records in the table.
>>
>>As for the deleted index: Do you really think by using a deleted() tag would speed up the query if in the selection of 0.1% (which are made by Article index) are none - aprox 5% deleted records ? This especially counts when this resultset of 0.1% of the table is actualy only about a few hundred or less records.
>>
>>Nah..... It's better to make sure you've high selective indexes on which an optimizer could really speed up things.
>>
>>Walter,

Andrus