Scribd
Upload
25 views

Exists in

IN is better than EXISTS when: 1. The subquery returns a small result that can leverage an index, while EXISTS would require a full table scan. 2. The outer table is relatively small, so IN can do an index probe and join, while EXISTS would do a full table scan. EXISTS is better than IN when: 1. The subquery returns a huge result that would be inefficient to fully materialize and distinct/index for an IN clause, while EXISTS can check for existence without materializing the entire result. So in summary, IN is preferred when the subquery result and outer table are small, while EXISTS may be better if either the subquery result or outer

Uploaded by

Saptarshi Mandal
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
25 views

Exists in

IN is better than EXISTS when: 1. The subquery returns a small result that can leverage an index, while EXISTS would require a full table scan. 2. The outer table is relatively small, so IN can do an index probe and join, while EXISTS would do a full table scan. EXISTS is better than IN when: 1. The subquery returns a huge result that would be inefficient to fully materialize and distinct/index for an IN clause, while EXISTS can check for existence without materializing the entire result. So in summary, IN is preferred when the subquery result and outer table are small, while EXISTS may be better if either the subquery result or outer

Uploaded by

Saptarshi Mandal
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
You are on page 1/ 2

Tom: can you give me some example at which situation IN is better than exist, and vice versa.

and we said... Well, the two are processed very very differently. Select from T! where x in " select y from T# $

is typically processed as: select from t!, " select distinct y from t# $ t# where t!.x % t#.y& The sub'uery is evaluated, distinct(ed, indexed "or hashed or sorted$ and then )oined to the original table ** typically. +s opposed to select from t! where exists " select null from t# where y % x $

That is processed more li,e: for x in " select from t! $ loop if " exists " select null from t# where y % x.x $ then -.T/.T T01 213-24 end if end loop It always results in a full scan of T! whereas the first 'uery can ma,e use of an index on T!"x$. So, when is where exists appropriate and in appropriate5 6ets say the result of the sub'uery " select y from T# $ is 7huge7 and ta,es a long time. executing " select null from t# where y % x.x t#"y$$. Then the exists will be faster as the time into T# could be less then the time to simply full distinct on. 8ut the table T! is relatively small and $ is very very fast "nice index on to full scan T! and do the index probe scan T# to build the sub'uery we need to

6ets say the result of the sub'uery is small ** then IN is typicaly more appropriate. If both the sub'uery and the outer table are huge ** either might wor, as well as the other ** depends on the indexes and other factors.

You might also like