× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



> From: Walden H. Leverich III
> 
> >From: Joe Pluta [mailto:joepluta@xxxxxxxxxxxxxxxxx]
> >Do you have any type of formal information on this.
> 
> Look at http://www.redbooks.ibm.com/redpieces/pdfs/sg246598.pdf,
> specifically figure 2-2 on page 12.
> 
> >or are you just guessing?
> 
> Guessing, no. Do I have a complete understanding of the 5.2 changes,
NO!
> I'm
> just beginning to comprehend the red piece above.

Thanks for the link.  The document is actually pretty straightforward.
Basically, IBM have implemented a sub-SLIC SQL Query Engine (SQE) that
should enhance queries, in some cases significantly, by moving much of
the work of a complex query under the covers.  Temporary objects will be
far more ephemeral, and will take advantage of the single level store
characteristics of the iSeries (which should in turn make them perform
bonzo compared to other architectures).  There are also SMP
enhancements.

This doesn't go without a cost.  The SQE is only invoked for certain
queries.  Those that are not processed by the SQE are handed back to the
CQE (the traditional, "Classic" Query Engine).  In fact, this handoff
can even add overhead to the process.

So what kinds of queries require the CQE?  Well, pretty much everything
of any complexity outside of queries.  INSERTs, UPDATEs, DELETEs all run
through the CQE.  Views.  Subqueries.  Derived tables.  LIKE or UNION.
If you have a logical file with SELECT/OMIT, or RENAME, or ALTSEQ, it
requires the CQE. LOBs require the CQE.

So what are we saying here?  Basically as far as I can tell, the SQE
enhancements basically make SQL run really well for what it was
originally intended to do: query data.  And it has little effect on
those cases where you try to replace traditional native I/O with SQL; in
fact, it has a slight negative impact in those cases.

No, I don't see anything in this document suggesting tat single record
FETCHes will outperform CHAIN any time soon.

Which makes perfect sense to me: upgrade SQL to be the fastest possible
ad hoc query mechanism on the planet, and use native I/O for business
logic.

Joe



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.