RE: SQL Update Performance

Elvis,

Since this a an update query and we're at v5r2, isn't the CQE always used?

It seems we're pretty much SOL. The query engine insists on joining ADDRINP in position 1, since
there's an IN predicate and a subselect involved. At least at v5r2. Perhaps the QE would be smarted
at v5r3, v5r4, v6r1.

Charles Wilt
Software Engineer
CINTAS Corporation - IT 92B
513.701.1307

wiltc@xxxxxxxxxx

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-
bounces@xxxxxxxxxxxx] On Behalf Of Elvis Budimlic
Sent: Thursday, February 07, 2008 3:23 PM
To: 'Midrange Systems Technical Discussion'
Subject: RE: SQL Update Performance

Make sure the following is in place for your original query:

- index (keyed LF) over ad1.key?
- index (keyed LF) over ctr.CINACT,ctr.CTRADR?

This problem should be solved with judicious use of proper indexing. You
should also try to verify if you get the same behavior with SQE & CQE
engine
(AND UPPER('x') = 'X' trick), as that can tell you if you're hitting some
query optimizer bug.

You can try forcing the join order, but that is in no way guaranteed to
work, or if it works it is not guaranteed to work in the future. It's a
workaround and that's never good as long term solution (hint: avoid it if
you can).

Something like this:
1) CRTDUPOBJ OBJ(QAQQINI) FROMLIB(QUSRSYS) OBJTYPE(*FILE) TOLIB(yourLib)
DATA(*YES)
2) UPDATE yourLib/QAQQINI SET QQVAL = '*PRIMARY 2' WHERE QQPARM =
'FORCE_JOIN_ORDER'
3) CHGQRYA JOB(*) QRYOPTLIB(yourLib)

Run your update statement now and see if you get a different join order
(i.e. 2ndary dial should become primary dial now).
Note that you have to tell the job where your update runs to use your
modified QAQQINI before you run the update statement.

Let us know what happens.

HTH, Elvis

Celebrating 11-Years of SQL Performance Excellence on IBM i5/OS and OS/400
www.centerfieldtechnology.com


-----Original Message-----
Subject: SQL Update Performance

I have an update that I am trying to do on V5R2:



UPDATE ADDRINP ad1

SET ad1.Addr1 = 'this is a test'

WHERE exists(

select * from contrcp ctr where

ctr.cinact = 'CC01' and

ctr.ctradr = ad1.akey)



This statement takes forever to run because of the join order the
optimizer
is choosing. ADDRINP is
in Join position 1 and CONTRCP is in join position 2. This is most likely
because I am updating
ADDRINP. Only problem is that there are 3,000,000 records in ADDRINP, and
putting it in join position
1 forces the whole file to be read in order to pick out 6 records to be
processed. Can anyone think
of a way to force CONTRCP to join position 1?



Mark Murphy

Star Base Consulting, Inc.

e: murphym@xxxxxxxxxx

--
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 e-mail transmission contains information that is intended to be confidential and privileged. If you receive this e-mail and you are not a named addressee you are hereby notified that you are not authorized to read, print, retain, copy or disseminate this communication without the consent of the sender and that doing so is prohibited and may be unlawful. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please delete and otherwise erase it and any attachments from your computer system. Your assistance in correcting this error is appreciated.