>>>>Of course it's optimizable.
>>>
>>>
>>>I didn't mean documentation wise.
>>>Cetin
>>
>>Same here. It is optimizable by observing the performance difference, not just by what the documentation says.
>
>Mike,
>My real world experience tells "locate" is slow that I wouldn't expect from a rushmore optimization (and yes I am talking about full optmizable expressions). I really can demonstrate and already published some code about it on foxite about a year ago or so. What I couldn't differentiate is if that is locate itself what is slow or Rushmore optimization is not as a big optimization as we always believed. A typical example is patient visits. A visits table have patientId (foreign key) and visitDate. Both indexed. When such a table have many records and on a network to augment its importance more:
>-Try locating a given patientID'd records that are between dStart and dEnd.
>-Next try just retrieving all records of that given Id and then filtering for date locally
>
>seek()+locate while however works fast. Hope it is clear now.

There may be ways to beat Rushmore, but a given command is Rushmore Optimized if the indexes improve performance above what would happen without the indexes.