Skip to Main Content
  • Questions
  • Evaluation order of where clause in ANSI join

Breadcrumb

Question and Answer

Chris Saxon

Thanks for the question, Giuseppe.

Asked: September 28, 2015 - 4:01 pm UTC

Last updated: May 13, 2021 - 5:12 pm UTC

Version: 10gR2

Viewed 1000+ times

You Asked

Hi,
I would like you to explain the behavior, that is the evaluation process and order of the following statement.

Starting point, two simple tables as follows:

Table "A":
COL_A
----
1
2
3
4

Table "B":
COL_B
----
1
2
3
5

Statement executed:
select a.col_a, b.col_b
from a join b
on a.col_a=b.col_b
where b.col_b <> 5

Result:
COL_A COL_B
----- -----
1 1
2 2
3 3

3 rows selected.

Why I keep expecting that left join would return row from table "A" with col_A = 4 with a corresponding null for col_B?

Sorry in advance if the question is silly.

Regards,
Giuseppe

and Connor said...

There is a subtle difference between the conditions *of the join*, and the conditions applied *after* the join.

Probably best shown as below:

SQL> select a.col_a, b.col_b
  2  from a left outer join b
  3  on a.col_a=b.col_b
  4  and b.col_b <> 5;  <== this is part OF the join

     COL_A      COL_B
---------- ----------
         1          1
         2          2
         3          3
         4

SQL> select a.col_a, b.col_b
  2  from a left outer join b
  3  on a.col_a=b.col_b
  4  where b.col_b <> 5;  <== this is AFTER the join

     COL_A      COL_B
---------- ----------
         1          1
         2          2
         3          3


btw, there are no silly questions :-)

Rating

  (3 ratings)

Is this answer out of date? If it is, please let us know via a Comment

Comments

Giuseppe Uleri, September 29, 2015 - 9:29 am UTC

Thank you for your answer, please confirm what follows: I was expecting value "4" on the first column because I forgot how null values works, that is applying the filter "after" the join null will be matched against "5" (of course returning false) and therefore excluding the entire row.

Best regards!
Connor McDonald
September 29, 2015 - 12:52 pm UTC

yes, that is a reasonable statement.

Additional info

Arka, December 22, 2015 - 10:08 am UTC

hi,
I completely agree with the argument provided by connor. However I would like to emphasis that the initial post by guiseppe shows
a join b

which I would read as
a inner join b

, so yes unmatched rows will always be out of the picture.
No need for the where clause.

order of execution

Rakesh, May 13, 2021 - 5:25 am UTC

in above query optimizer 1st execute the where clause or 1st it will join the table ?
Chris Saxon
May 13, 2021 - 5:12 pm UTC

What happens depends on the join type. Broadly speaking:

- If it's a hash join, the database will filter the rows on each table, then join them
- For nested loops & merge joins, the database can apply both the join and where clause when reading the inner table

The precise details depend on the indexes available, (estimated) number of rows processed, etc.