RE: SQL vs native access

["Joe Pluta" <joepluta@xxxxxxxxxxxxxxxxx>]

> From: Walden H. Leverich III
> 
> I think that was true prior to 5.2. In <=5.1 SQL actually accessed
data
> through the same SLIC primatives as single record operations. However,
in
> 5.2 SQL has a new query engine (below the MI) and its own set of SLIC
> primatives so I'm tempted to say that common sense may see a change.

And as a followup, I'd still be interested to see how an SQL SLIC
primitive could somehow be faster than the same primitive for native
I/O.  For a single record keyed CHAIN on a native file, it's pretty much
search the index for the key (this is all low-level), then retrieve the
record pointed to.  How exactly are you going to do this faster in SQL?
Now, if you're performing a prepared statement against a predefined
index, my guess is that you could possibly get equivalent performance.
If you have to parse the SELECT statement, you have the additional
parsing overhead.  I can't see how you would get any faster.

This is what I mean by common sense.  Computers are not magic.  They
perform operations.  The reason SQL is faster on sets is not because it
uses faster I/O electrons, it's because it doesn't have to jump up and
down between the application and the low-level functions during the
processing of the set.  With single record I/O, there is no such
benefit.  So I'd be really interested to see the rationale that implies
that somehow SQL could be faster than native I/O.

Joe