Re: Using host variables in SQLRPGLE doesn't seem to be working....INclause

I was not responding to the original scenario, but to the revised scenario as suggested by Michael; i.e. where a temporary table of test predicates as rows would need to be created in order to effect the same original results, but using the subselect instead of host variables. Thus I was responding to the inquiry about the additional SELECT in the revised scenario, as compared to only one SELECT in the original scenario; that while the additional SELECT does add somewhat more overhead than literals passed in host variables, I was suggesting that the maintenance of the "WorkTable1" temporary table would add the most noticeable impact for that scenario.

Regards, Chuck

On 1/12/11 5:41 AM, Bryce Martin wrote:

The select is not going at a temporary table, it's going at a static
table. The table has cleanliness rules applied to the input data and
the search string is cleaned according to those same rules so to
maximize matches of the searches. I will take a look at these
different techniques today and try to write a program to test each
one's efficiency.

On 1/10/11 12:57 PM, Bryce Martin wrote:

Won't the multiple select statement have a negative impact on
performance compared to a list of predetermined values?

"Schutte, Michael Don 01/10/2011 03:36 PM wrote:

Change this to...

Select Cast(rncust As Numeric(6,0)),
Cast(rnseq As Numeric(4,0)),
Cast(rntype As Numeric(2,0)),
rnword1, rnword2, rnword3, rnword4, rnword5
From rcm002pf
Where rnword1 in (select WorkKey1 from WorkTable1)

The real issue for performance impact would be for the
/maintenance/ on the work table [i.e. drop, create, open, insert,
clear...] rather than the much smaller impact of running and using
the result of the subselect. If the input string is as easily
parsed as the example, then I believe a recursive CTE breaking the
string into rows [of a true temporary file as created by the
database scoped to that SELECT] would perform noticeably faster
than using a user-created work table. >