Hi Mike,

>>>To my best knowledge, this isn't correct. Rushmore only loads matching indexnodes into memory and searches the first one in a simular way as the SEEK command. Non-mathing indexnodes (besides the ones to reach the matching ones) are left alone and are never addressed.<<

>We'll never know until Microsoft explains exactly what happens. I thought Chris Probst's infamous FPA article proved that the amount of data moved across the wire for the relatively few deleted records was large enough to account for the entire tag.

I beg to differ; The case showed in the article, and as I recall some cases provided by other UT members was that when SET DELETED = on all DML commands have a logical SET FILTER TO DELETED() = .F.. In this case all indexnodes in the DELETED() tag with the value of .F. are downloaded, which in fact is in most cases the vast majority of records in the table.

One can easely test this by setting SET DELETE to OFF and fire a DML Command for all DELETED() records. The difference between querying for DELETED() records and NON-DELETED() records shows that only the matching indexnodes are downloaded, not the entire indextag.

>>>As you have been pointing out LOCATE is designed to work with sets of records, and has to download all the matching indexnodes into memory. Besides the other overhead of using rushmore, this is the reason that seek always will be faster than locate.<<
>
>What other overhead of using Rushmore. Rushmore is the overhead (relative to the seek).

SEEK only downloads indexnodes to search for the fist matching one. Rushmore downloads all the matching indexnodes. When rushmore finds more than one index to make use off, it loads the matching (and only the matching) indexnodes of all indextags, fires an indexnode query (indexnodes are handled like records) and constructs a table which define the actual resultset of the rushmore optimizable part.

The overhead off rushmore is thus:
-It has to determine which tags it can use for optimizing
-It searched beyond the first found indexnodes for other matching ones
-It stores them in memory
-It fires and indexquery (only for two tags or more)
-Returns the result

This mechanism is not such a big secret, most (R)DBMSs optimizes their queries this way. The relative strength in the VFPs implementation is the use of fixed length records (Records can be looked up very quickly) and the ability to compress the indexvalues in a very fast way. Smaller indexes consume less memory and thus are faster.

Only the very details about rushmore and the actual implementation are keeped a secret; the global lines are very well known.

Walter,