Beacuse of the outer join, the optimizer had to ignore the inlist predicate and therefore the filter factor for the table became 1 (= all rows), manifested in TB_SEL 1.0000.

At 06:29 AM 7/31/2003 -0800, you wrote:
Thanks to Wolfgang for spotting the problem. It was not the inlist iterator at all but an outer join! The NOT NULL predicate invalidated the outer join, so the optimizer was smart enough to make a different decision. I am still perplexed as to why the table access information was so radically different, but in light of the new finding, an explanation can be found.

The lesson learned here is to not to focus on a 'problem' until you fully understand the whole situation.

Daniel

Wolfgang Breitling Oracle7, 8, 8i, 9i OCP DBA Centrex Consulting Corporation http://www.centrexcc.com


-- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Wolfgang Breitling INET: [EMAIL PROTECTED]

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).

Reply via email to