|
> 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
This mailing list archive is Copyright 1997-2026 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.