RE: V5R3: OPNQRYF vs Imbedded sql -- MIDRANGE-L

Eric

That's the official party line, as I see it. Not that it's not true, just that it smells of a marketing "story" to "unify" the iSeries with the rest of IBM. That IS a problem, as many at the other divisions still might not know that the 400 still exists in some manifestation.

The beauty of the object-oriented design is, they can just plug in lots of different processing node types into the access plan tree. And the group putting it together was, when I was contracting there a couple years ago, trying to take advantage of what other divisions had already learned. I'm sure it still is. That did not used to be how it worked - Rochester was this fortress - the book is right, in my view. That's changing a little, I think.

I do not know why the non-SQL tools are not sent down to SQE (runs completely in SLIC). I suspect they will always be around but will not benefit directly from any performance gains that the new engine provides. SQE for now is limited to read-only, IIRC. And some things in an SQL statement will still force it back up to CQE. There's an info APAR somewhere that gives the conditions for each path. One of the problems was, a statement might be directed to SQE, which finds other reasons not to process it and sends it back up to CQE (runs mostly above MI). Don't know if that is still the case, or does the router (QSQROUTE or something) have better smarts yet.

Maybe if all functions can be handled by SQE, they'll eliminate CQE and have all the query engines go through SQE - that'd be nice, but don't hold your breath. Besides, tens of programmers would need to find other positions. ;-)

Statistics hold out much promise, IMO. They used to be able to hog your system - pretty hard-hitting on the old I/O - but that's some better, I believe. I don't have first-hand info on that. But the more the optimizer can know about the distribution of data in a column, the better it can decide what to do. Stats will help that when there is not an index on a column, which already has statistical info.

UffDa - too much said.

Later
Vern

At 01:21 PM 6/16/2004, you wrote:

Rob,

As I recall, the SQE is written with object oriented design, so that the
optimized DB2 code for other platforms can be shared with our flavor of DB2.
SQE has better statistical analysis capabilities that allow the optimizer to
make more intelligent decisions about how to perform efficiently.

Eric DeLong
Sally Beauty Company
MIS-Project Manager (BSG)
940-898-7863 or ext. 1863

-----Original Message-----
From: rob@xxxxxxxxx [mailto:rob@xxxxxxxxx]
Sent: Wednesday, June 16, 2004 8:50 AM
To: midrange-l@xxxxxxxxxxxx
Subject: V5R3: OPNQRYF vs Imbedded sql


I was reading an article at
http://www.midrangeserver.com/fhg/fhg061604-story01.html
and it talked about the differences between the newer SQL Query Engine
(SQE) and the Classic Query Engine.  One of the things it said was that
OPNQRYF, Query/400, and the QQQQry API all will use the CQE.  Deprecated
products?  Poorer performers?

Rob Berendt
--
Group Dekko Services, LLC
Dept 01.073
PO Box 2000
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.


--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.