RE: SQL Update Performance -- MIDRANGE-L

Elvis,

Found a post on DBforums.com from Kent Milligan"

"The problem is that our current update/delete join support can only
update/delete a join table in the first position - so by using a join to
implement the subquery the join order is fixed (thus causing the table scan).

The join rewrite is not used when the subquery contains an aggregate function or a grouping clause - I
suppose you could see if you could alter your subquery to try and get a non-join technique used and
see if that performs any better."

So we tried this:

select * from hlthitgdta/addrinp ad1
WHERE ad1.akey in (select ctradr
from hlthitgdta/contrcp
where cinact = 'CC01'
group by ctradr
)

Not sure what it's doing, but my emulator session stops responding!!!

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 Wilt, Charles
Sent: Friday, February 08, 2008 12:12 PM
To: Midrange Systems Technical Discussion
Subject: 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.
--
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.