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
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..
At 06:29 AM 7/31/2003 -0800, you wrote:
Thanks to Wolfgang for spotting the problem. It was not the inlist
iterator at
Is the INLIST ITERATOR unable to use the index unless we specify NOT NULL? I wanted to
bounce this off the list before we log a TAR.
We are examining the performance of a query and I am trying to understand why an
INLIST ITERATOR is not used if there is not an explicit IS NOT NULL predicate
Can you post the sql, or even the 10053 trace up to the GENERAL PLANS
section. That would also answer the question which exact version/release
of Oracle 9?
At 12:59 PM 7/29/2003 -0800, you wrote:
Is the INLIST ITERATOR unable to use the index unless we specify NOT NULL?
I wanted to bounce this
