RE: SQL Update Performance

["Luis Colorado" <LuisC@xxxxxxxxxxxxxxxx>]

If this is a Java project, you might be better off creating a cursor similar to the view I sent you previously, and then update the data using the cursor.

 -----Original Message-----
From: 	midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx]  On Behalf Of Murphy, Mark
Sent:	Thursday, February 07, 2008 5:48 PM
To:	Midrange Systems Technical Discussion
Subject:	RE: SQL Update Performance

I am guessing that it is using CQE since all my physicals are DDS defined.  The files are old, the SQL
is new for a Java project.

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

Being that UPPER trick made no change I am guessing that query is going down
CQE path to begin with.  You can confirm this is the case or not using
Visual Explain (VE).  
VE will also tell you if there are any additional indexes advised.
VE should also tell you if it's using a table scan and hopefully why it's
using it.  If it doesn't, debug messages will probably tell you that
(STRDBG).

Field being updated isn't your key field by any chance?  
If that's the case, you're stuck with table scan no matter what you do.

Elvis

Celebrating 11-Years of SQL Performance Excellence on IBM i5/OS and OS/400
www.centerfieldtechnology.com
 
-----Original Message-----
Subject: RE: SQL Update Performance

My indexes are good, the UPPER trick and FORCS_JOIN_ORDER made no
difference.