CODEWITHSUNDEEP
sqlperformanceoracle-databaseinner-joinwhere-clause
invertigo
invertigo

Reputation: 6438

Oracle SQL Query Filter in JOIN ON vs WHERE

For inner joins, is there any difference in performance to apply a filter in the JOIN ON clause or the WHERE clause? Which is going to be more efficient, or will the optimizer render them equal?

JOIN ON

SELECT u.name
FROM users u
JOIN departments d
ON u.department_id = d.id
AND d.name         = 'IT'

VS

WHERE

SELECT u.name
FROM users u
JOIN departments d
ON u.department_id = d.id
WHERE d.name       = 'IT'

Oracle 11gR2

Upvotes: 11

Views: 15206

Answers (2)

Emil Daniel Ordoñez Avila
Emil Daniel Ordoñez Avila

Reputation: 26

I prefer putting the filter criteria in the where clause.

With data warehouse queries, putting the filter criteria in the join seems to cause the query to last significantly longer.

For example, I have Table1 indexed by field Date, and Table2 partitioned by field Partition. Table2 is the biggest table in the query and is in another database server. I use driving_site hint to tell the optimizer to use Table2 partitions.

select /*+driving_site(b)*/ a.key, sum(b.money) money
  from schema.table1 a
  join schema2.table2@dblink b
    on a.key = b.key
 where b.partition = to_number(to_char(:i,'yyyymm'))
   and a.date = :i
 group by a.key`

If I do the query this way, it takes about 30 - 40 seconds to return the results.

If I don't do the query this way, it takes about 10 minutes until I cancel the execution with no results.

Upvotes: 0

Justin Cave
Justin Cave

Reputation: 231781

There should be no difference. The optimizer should generate the same plan in both cases and should be able to apply the predicate before, after, or during the join in either case based on what is the most efficient approach for that particular query.

Of course, the fact that the optimizer can do something, in general, is no guarantee that the optimizer will actually do something in a particular query. As queries get more complicated, it becomes impossible to exhaustively consider every possible query plan which means that even with perfect information and perfect code, the optimizer may not have time to do everything that you'd like it to do. You'd need to take a look at the actual plans generated for the two queries to see if they are actually identical.

Upvotes: 14

Related Questions