Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
Home
Discussion Groups
Database Servers
DB2InformixIngresMS SQLOraclePervasive.SQLPostgreSQLProgressSybase
Desktop Databases
FileMakerFoxProMS AccessParadox
General
General DB TopicsDatabase Theory
Related Topics
Java Development.NET DevelopmentVB DevelopmentMore Topics ...

Database Forum / DB2 Topics / July 2007

Tip: Looking for answers? Try searching our database.

IN versus ANY versus EXISTS

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
aj - 23 Jul 2007 19:51 GMT
DB2 8.2 LUW FP14

Is there any real difference between
  select blahblahblah... where blah IN (select blah......)
versus
  select blahblahblah... where blah = ANY (select blah.....)
versus
  select blahblahblah... where exists (select blah.....)

Is one more ANSI than another?  Which is most portable?

TIA

aj
David Portas - 24 Jul 2007 20:47 GMT
> DB2 8.2 LUW FP14
>
[quoted text clipped - 10 lines]
>
> aj

IN, ANY and EXISTS are all ANSI SQL 92.

A IN (B)

is equivalent to

A = ANY (B)

In fact the SQL standard defines IN by using the ANY syntax.

EXISTS is entirely different. Probably you meant to imply some correlated
subquery in place of some simple subqueries in your other examples. Without
seeing the actual queries, DDL etc I won't speculate on whether such queries
might be equivalent.

Signature

David Portas

Brian Tkatch - 25 Jul 2007 13:57 GMT
>DB2 8.2 LUW FP14
>
[quoted text clipped - 10 lines]
>
>aj

Yes. IN means the compiler needs to put together a result set, and see
if it matches. EXISTS wll use any availible INDEX.

For smaller reult sets IN() is usually faster, for larger use EXISTS.
In some cases execution time will be the same, in others, there may be
a significant difference.

B.
Knut Stolze - 25 Jul 2007 19:18 GMT
>>DB2 8.2 LUW FP14
>>
[quoted text clipped - 13 lines]
> Yes. IN means the compiler needs to put together a result set, and see
> if it matches. EXISTS wll use any availible INDEX.

I wouldn't draw such a conclusion.  The optimizer could rewrite one form
into the other and, thus, result in the same access plan.

Signature

Knut Stolze
DB2 z/OS Utilities Development
IBM Germany

Brian Tkatch - 25 Jul 2007 19:49 GMT
>>>DB2 8.2 LUW FP14
>>>
[quoted text clipped - 16 lines]
>I wouldn't draw such a conclusion.  The optimizer could rewrite one form
>into the other and, thus, result in the same access plan.

You know, the optimizer really gets in the way here. :P

B.
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.