Inlist operator vs join

Question

Dear Sirs, hope question will be new in this forum.
I've found out following :
select count(*) from TEST_TAB s
where hash_key = :hk
and( R$APP in (x1, x2, ..., x10 )
or R_CALLS_LOG in ( y1, y2, ..., y756)
run time: 380 sec
select count(*) from TEST_TAB s
where hash_key = :hk
and( R$APP in (x1, x2, ..., x10 )
or R_CALLS_LOG in ( select n from BUF_TAB)
), where BUF_TAB contains list of values of 1st query
run time: 17 sec.
Description of TEST_TAB
SQL> desc TEST_TAB
Name Type Nullable Default Comments
LDN NUMBER
CID NUMBER Y
R_CALLS_LOG NUMBER Y
TRANSAC NUMBER Y
R$APP NUMBER Y
STRT DATE Y
ROW_ID ROWID Y
DEST_HASH_KEY NUMBER Y
HASH_KEY NUMBER Y
INDEXES: NO
LIST-PARTITIONED: BY "HASH_KEY"
RECORDS in tested section: ~ 1.5 mln
It seems that INLIST operator in WHERE works dramatically slowly that join with the same list stored in separate table.
Is it true for all cases or there is optimal amount of elements in filtration list when INLIST operator will be still best choice?
Thanks in advance.

Answer 1

user618999 wrote:
Is it true for all cases when question has only 1 parameter - amount of items in list, while
TEST_TAB has no indexes ...As rgeier pointed out don't think that one query technique is better than another in all circumstances. You can over time see what usually works, but nothing is always true. You've found a situation where the inlist iterator works less efficiently but based on other circumstances the join might not work as well.
An indexed lookup for a table join or subquery is usually a good choice for faster retrieval than a full table scan - unless you need to access all of the rows in the list, in which case it will probably be slower. Without an index an in list might be faster.
I personally don't use in lists a lot, preferring joins or correlated EXISTS subqueries when the subqueries are properly lindexed. If I remember correctly a hard-coded in list has a limit of 1000 items anyway. In lists might be more efficient if they return a very small set of rows, perhaps less than 5 for fewer rows to search through, and if the underlying query (if any) can only be executed once to produce the list.
Adding to the confusion of tuning is that fact that recent versions of oracle can perform query transformations before execution. That is, the query can physically change before execution if the optimizer thinks the change will work better. Thus, in lists and table joins can sometimes be converted to the other. In some cases entire table joins can be added or eliminated.
Edited by: riedelme on Oct 1, 2009 12:55 PM