• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 271
  • Last Modified:

Exists versus In

This was an interview question asked:

Is there any scenario where exists would be used but not  IN.
 
My answer: Exists returns boolean value and IN returns a value and exists is faster performance-wise. They donot want to know about the performance but they wanted to know a scenario where only Exists could be used but not IN
0
d27m11y
Asked:
d27m11y
  • 3
  • 2
  • 2
  • +2
1 Solution
 
slightwv (䄆 Netminder) Commented:
>>and exists is faster performance-wise

Tom Kyte explains why this may not be true:
http://asktom.oracle.com/pls/asktom/f?p=100:11:::::P11_QUESTION_ID:953229842074

>>wanted to know a scenario where only Exists could be used but not IN

Of the top of my head I cannot think of one.  I'm sure some other Expert will have one if I cannot think of one later.
0
 
DavidSenior Oracle Database AdministratorCommented:
Prior to 10g, EXISTS was preferred for a small result set.  The CBO has long since been improved.
0
 
d27m11yAuthor Commented:
How about NULL values, am not sure.. can anyone shed light ?
0
Concerto's Cloud Advisory Services

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.

 
slightwv (䄆 Netminder) Commented:
>>How about NULL value

There is the example I couldn't think of.

IN lists cannot process nulls where EXISTS can.

Take the following test case:
drop table tab1 purge;
create table tab1(col1 char(1), col2 char(1));

insert into tab1 values('a','a');
insert into tab1 values('1',null);
commit;

select t1.col1 from tab1 t1 where exists (
	select null from dual
);

select t1.col1 from tab1 t1 where col2 in (
	select null from dual
);

Open in new window

0
 
SurranoSystem EngineerCommented:
@slightwv I haven't tested this but lines 8-10 don't look like making any sense. It will return all rows since select anything from dual will always be a non-empty resultset i.e. exists evaluates to constant true.

I believe exists makes sense on a relatively small table if you can use a good where condition e.g. using an index of a huge table:

select * from smalltable where exists 
(select null from hugetable where hugetable.indexedfield = smalltable.somefield);

select * from smalltable where somefield in (select indexedfield from hugetable);

Open in new window


As far as I can tell Oracle (as well as MySQL or PostgreSQL) would do something like:
- for IN: perform full table scan on hugetable and join the resultset with smalltable
- for EXISTS: perform full table scan on smalltable and a relatively small number of index searches on hugetable.

But I can imagine that one or more of the above systems, also possibly depending on table statistics, software version and perf tuning config, would rewrite the IN query to EXISTS or vica versa.
0
 
DavidSenior Oracle Database AdministratorCommented:
To the interview question, then, your answer seems to be "no".  Disregarding performance as directed, IN does not currently have any declarative restriction.
0
 
awking00Commented:
I think there might be cases when exists can be used but not in. Something like the following where you want to get an audit report but only where there is an error in the error_log table for today:

select * from audit_table where exists
(select 1 from error_log where errdate > trunc(sysdate));
0
 
SurranoSystem EngineerCommented:
This can also be rewritten as "IN":

select * from audit_table where 1 in
(select 1 from error_log where errdate > trunc(sysdate)); 

Open in new window


And this is actually a proof of concept: the following two boolean expressions are equal:

exists (select 1 from ...) 
1 in (select 1 from...)

Open in new window

Note that you can replace 1 with any non-null constant of any type.

There is a nuance in the original question though; "where exists would be used but not  IN." The concept above is not about "would" more like "could". Just in case it matters.
0
 
awking00Commented:
Surrano, good point. I didn't think about the use of a literal value in a select of that literal value.
0
 
slightwv (䄆 Netminder) Commented:
>>is not about "would" more like "could". Just in case it matters.

Even though you discount my over-simplified test case as not making any sense.  I stand by my comment.

When nulls are involved, EXISTS will work an IN will not.  I can use EXISTS to look for nulls and I cannot rewrite it to use a null in an IN list.

I cannot say:   ... where column in (a,b,c,null)
0

Featured Post

Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

  • 3
  • 2
  • 2
  • +2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now