RE: SQL vs native access

>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.

-Walden

------------
Walden H Leverich III
President
Tech Software
(516) 627-3800 x11
(208) 692-3308 eFax
WaldenL@xxxxxxxxxxxxxxx
http://www.TechSoftInc.com 

Quiquid latine dictum sit altum viditur.
(Whatever is said in Latin seems profound.)
 

-----Original Message-----
From: Joe Pluta [mailto:joepluta@xxxxxxxxxxxxxxxxx] 
Sent: Friday, August 22, 2003 4:27 PM
To: 'RPG programming on the AS400 / iSeries'
Subject: RE: SQL vs native access 


> 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

_______________________________________________
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.