Mike Yearwood
Toronto, Ontario, Canada
General information
Category:
Databases,Tables, Views, Indexing and SQL syntax
>>>>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.
Previous
Reply
View the map of this thread
View the map of this thread starting from this message only
View all messages of this thread
View all messages of this thread starting from this message only