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
>
>IIRC, once upon a time we had some theoretical explanation for the behavior of Locate: it builds a bit map of records that it finds. Depending on the size of the table, the physical layout of these records in the table etc, this map may take some time to build - but then a loop with do while found() and a Continue before the end of the loop would be blazingly fast.
>
>Being spoiled by Scan/Endscan's elegance, I haven't tried this ever since. The Locate/Continue looks somewhat clumsy, compared with Scan/Endscan, so it seems I'm avoiding it. Maybe I shouldn't... but I just don't think in that direction.
From Rushmore's perspective only SCAN+ENDSCAN = LOCATE+CONTINUE # SQL
SEEK first is often faster, but you cannot build a system only using seek and then make that work with a different backend. I prefer one approach. For me, Seek is relegated to incremental searches in SQL generated cursors and indexes are only to show the SQL generated cursors in different orders.
>
>>seek()+locate while however works fast. Hope it is clear now.
>
>Still haven't found anything that beats "seek+scan while"'s speed.
seek + locate while = seek + scan while from Rushmore's perspective.
Previous
Next
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