|
> >I guess because I don't believe in magic, I'd like to know what the basic >concept is that allows SQL to outperform an indexed read for pure >transaction processing tasks. > >Joe > > A few possibilities: The new sql may take advantage of multiple processors on the system. Database search code may be optimized re the instruction pipeline of the powerpc processor. The traditional record at a time io code of os400 may have 30 yrs of chgs, patches, optimizations, add ons ... Any chg to this code introduces the possibility of bugs. -Steve Richter >> -----Original Message----- >> From: John Taylor >> >> Joe, >> >> I agree with you if you're talking about single record key >> positioning, but >> READE/SETLL/OPNQRYF imply (to me) set based processing. SQL can often >> outperform native access for sets. Of course, OPNQRYF itself uses the same >> underlying SQL support, so I wouldn't have included it in the >> same family as >> the native opcodes. >> >> Here is a link to an interesting read about indexing in DB2/400, if you're >> interested in nitty-gritty details: >> >> http://www.iseries.ibm.com/developer/bi/documents/strategy/strategy.pdf >> >> >> John Taylor > >_______________________________________________ >This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list >To post a message email: MIDRANGE-L@midrange.com >To subscribe, unsubscribe, or change list options, >visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l >or email: MIDRANGE-L-request@midrange.com > >
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 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.
midrange.com
