× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Now you are just making me worry. Because I've another process where I need
to perform a reverse sub-select query, which could give me different result
depending on how the sub-select is executed.

declare BL1025INPCursor cursor for
select * from BL1025INP a
where
not a.inseq# in
(select INSEQ#
from BL1025INP b
where
b.inerrFlg = 'Y'
group by
INSEQ#);

Notice this time I use the "NOT a.inseq# in(...)". For each record I
fetched in my RPG program, I'll need to perform additional validation, if it
failed, I'll then update the INERRFLG to Y. If the sub-select is execute
for each row fetch, it could terminate my fecth loop prematurely.....

I guess to be safe, may be I need to change it to use with clause.....



"CRPence" <CRPbottle@xxxxxxxxx> wrote in message
news:mailman.31950.1299096458.2702.midrange-l@xxxxxxxxxxxx...
Proof by counter-example can easily show otherwise. One should not be
so sure to discount a possible implementation for the IN predicate derived
from a SELECT. Again, one should ask the optimizer what plan was built
for the given query, to best know the answer to the question by the OP.

Regards, Chuck

On 3/2/11 10:50 AM, Schutte, Michael D wrote:

The OP original query is NON correlated. There's nothing for the two
files to join on. In that example, the sub query would get executed
once. However, if there was a.fld = b.fld in the sub query then it
would/could/should execute a join, thus repeating the subquery over
and over again for each row from table a.

CRPence on Wednesday, March 02, 2011 1:32 PM wrote:

On 3/2/11 10:02 AM, hockchai Lim wrote:
For the SQL below, does any one know if the sub-select in the
where statement gets execute only once or it gets execute for
each row in BL1025INP file?

The answer is in the domain of the optimizer, not of a reviewer of
the SQL. Even if known what the optimizer chooses today, does not
imply what the optimizer will choose tomorrow. However very
probably the subselect is not performed, not even as a
parameterized query, for every row in a full table scan. Most
likely that query is implemented as a join on INSEQ# with either an
existing index on that column, a temporary index on that column, or
a full table scan if the cardinality of the matches can be inferred
or cardinality of the distinct values is low according to available
statistics.


update
BL1025INP a
set
a.INERRFLG = 'Y'
where
a.inseq# in (
select inseq#
from BL1025INP b
where
b.inerrFlg = 'Y'
group by
INSEQ#)
/* perhaps adding to the above WHERE clause: */
and a.inerrflg<>'Y' /* no reason to change those.? */

So... Ask what the optimizer decided, EXPLAIN the statement
[query] in iNav. Even the deprecated "optimizer debug messages" are
likely to explain the query sufficiently to infer the subquery is
not run repeatedly.




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.