>>This is correct when your searching for a unique record (there is only one matching record). But when you're searching for an expression which matches more than one record, it will become more likely that the first candidate will be more to the front of the file, which means that the avarage time of a non-optimizable LOCATE will drop significantly.
>>
>>OTOH if you are using the LOCATE to check if a record does exist, rushmore is likely to be the winner as it can detemine quite quickly if a matching record does exist.
>
>I'm missing something here, are you saying that in this
>case an optimizable LOCATE would be faster than a
>SEEK?

No, I did try to compare an optimized LOCATE with a NON optimized LOCATE. A seek without a filter will always be faster than a LOCATE.


>>I think there are lot's of factors involved which determins which is faster; to name a few which probably are:
>>- The selectivity of the optimizable part of the FOR clause
>>- If the indexes are balanced
>
>Walter would you comment on these two items. I'm
>not familar with the terms "selectivity" and
>"balanced index".


Selectivity is how selective an query is. IOW if the query select only a few records out of a million table, we say that selectivity is high. OTOH if you select about half of the table, selectivity is low. Rushmore has to load all matching indexnodes to optimize, if the value to search has a high selectivity, rushmore downloads only a small number of indexnodes (good performance), if the value to search has a low selectivity, rushmore has to download many indexnodes (less performance).

A balanced index refers to the internal structure of the index which in fact a binary tree. If you're familiar with the concept of binary trees, you'll know that if you add and delete nodes the there can be a situation where the left half of the tree contains less nodes than the right half; IOW the B-tree becomes unbalanced. If you own a FoxPro 2.x developersguide just see the chapter about Index File structure (Page A-25 for the FPW 2.5 developer guide).


>>- The existance of NON - optimizable parts of the FOR clause
>
>NOT DELETED() for instance?

No, the non optimizable part of a FOR clause in for example a LOCATE or SCAN, IOW if a rushmore command is FULL optimizable or just partial optimizable.

>>As a result I can only conclude, you've got to test if rushmore is helpfull or not in your case. I do step off the idea that there is a general rule of thumb; it simply depends on too many factor IMO.
>
>One more thing. Outside of having the code right
>there in front of you, how would one confirm the behavior
>of index processing (i.e. whether it reads the whole index
>and scans it sequentially)?

In both cases, SEEK and rushmore, searches trough the binary tree of an index. In the case of SEEK, it stops reading the index until it finds an indexnode which matches the value to search or reaches the end to the B-tree. Rushmore OTOH searches trough the B-tree for ALL matching nodes, and downloads all matching nodes into memory for rushmore optimization. IF rushmore has to download more indexnodes, it consumes more resources than SEEK. Therefore SEEK is just faster than LOCATE.

Walter,