RE: Embedded SQL with Coalesce

Vern and Chuck-

Thanks for your feedback I ran some tests here on a small file and while not exhaustive, I think the results make sense to me.

Selecting on a simple where clause similar to A.artxyr = 'xxxyyyy' resulted in the same plan as selecting on A.artxyr = 'xxx' || 'yyyy'. The interesting thing was the optimizer actually seemed created a new plan for the new query even though the resulting plans were the same. Both plans used an index probe over the index created for the selection criteria I used.

When I changed the query to select on subtring(A.artxyr,4,4) = 'yyyy' then it created a different plan that had to use an index scan and took longer.

Thanks.
-Tom


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Vern Hamberg
Sent: Wednesday, May 30, 2012 9:51 AM
To: RPG programming on the IBM i / System i
Subject: Re: Embedded SQL with Coalesce

Tom - I'll jump in here - the calculation has to be done for every record you are testing - this prevents the use of any index on A.artxyr.

This is generally true, and may depend on where the calculation is.

Also, I'm inclined to think implicit casts may have some bearing on performance. Not sure, would have to run through Visual Explain to see.

In this case, it'd be easy enough to run 2 SELECTs in Navigator, one with this concatenation of 2011 and a constant that is a valid value for RPTTXYR. The other would use directly the value that resulted from the concatenation.

HTH
Vern

On 5/30/2012 10:06 AM, Tom E Stieger wrote:

Birgitta-

On a side note, why does this matter for performance?


-Tom Stieger
IT Manager
California Fine Wire




-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Birgitta Hauser
Sent: Tuesday, May 29, 2012 10:38 PM
To: 'RPG programming on the IBM i / System i'
Subject: AW: Embedded SQL with Coalesce

This line looks suspicious to me:
and A.artxyr = 2011 || :RPTTXYR

To me too!
For performance issues you should avoid concatenating those things in
the SQL statement, calculate the variable value in your RPG and use it
as
follows:

MyVar = '2011' + RPTTXYR;

Select ...
Where a.ARTXYR = :MyVar

Mit freundlichen Grüßen / Best regards

Birgitta Hauser

"Shoot for the moon, even if you miss, you'll land among the stars."
(Les
Brown)
"If you think education is expensive, try ignorance." (Derek Bok) "What is worse than training your staff and losing them? Not training them and keeping them!"


-----Ursprüngliche Nachricht-----
Von: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] Im Auftrag von Scott Klement
Gesendet: Tuesday, 29.5 2012 23:58
An: RPG programming on the IBM i / System i
Cc: Dave Boettcher
Betreff: Re: Embedded SQL with Coalesce

Hi Dave,

This line looks suspicious to me:

and A.artxyr = 2011 || :RPTTXYR

Are you truly trying to concatenate a number (2011) to a variable? If so, SQL will have to implicitly do some casting to make it work, which might be where the issue is.

The other thing that comes to mind is the FETCH statement -- I'm
mainly suspicious of the FETCH because you say it works in iNav, which
implies the issue is something you wouldn't have done in iNav (such as
a fetch)

It's possible that SQL is implicitly casting between a numeric/character data type in the fetch... maybe because the receiver data type doesn't match the database data type. Worth checking into...

-SK



On 5/29/2012 4:49 PM, Dave Boettcher wrote:

Kurt, Good guess. I still receive the error either way.

Jonathan , You're right it was defined as character. I had great
hopes for this one but still receive the error. I should only need
the coalesce on the Declare statement not the fetch, right?

Tom, the phones are signed numeric and so I tried the + signs. It
seems that a zero shouldn't need to have a sign but it was worth a
shot.

--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing
list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/rpg400-l.


--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing
list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/rpg400-l.

--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at http://archive.midrange.com/rpg400-l.