RE: SQL vs native access

> From: Walden H. Leverich III
> 
> >From: Joe Pluta [mailto:joepluta@xxxxxxxxxxxxxxxxx]
> >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.
> 
> OK, as I mentioned in my last e-mail, I'm just beginning to understand
the
> red piece, so this is somewhat a guess, but...
> 
> Different buffering schemes, different buffers, the ability to read an
> index differently (backwards for example) etc.

Yeah, this is definitely a guess <grin>.  You're really reaching here.
Since the iSeries is a single level store, "buffering" is handled
completely outside of the application accessing the object.  Indices and
tables are objects, and unless you can point to something specific in
the document, I will continue to believe that the access to those
objects is going to be exactly the same for both SQE and native I/O,
since it's been tuned and optimized for decades.

And I don't even understand what "the ability to read an index
differently" means.  An index is a set of keys and data pointers (this
is conceptually speaking; the implementation is a little different for
Encoded Vector Indices, but the concept is the same).  Index scans are
pretty much just pointer arithmetic and compares, and I don't think SQL
is going to do it any differently.

Let me know if you see something different from the documents.

Joe