Outer join vs. 'SELECT in SELECT'

Question

Hi All,
I am generally curious about which method to use between a Outer join and 'SELECT in SELECT'. We can have same result with both methods.
My question is, for real life complex queries, which method is more efficiant? less resource intensive? Any thories you guys have?
I am on Oracle 10.2 on lunix.
See my example below
-- First table
create table emp
id   number,
name varchar2(1000),
constraint emp_pk primary key ( id )
-- second table. There will be 1 record, for few of the records in EMP table, in this table
create table leave
id     number,
emp_id number,
leave_date date,
constraint leave_pk primary key (id),
constraint leave_fk foreign key ( emp_id ) references emp
create index leave_idx_1 on leave ( emp_id ) ;
-- Populate some sample data in there
insert into emp (id, name)
select object_id, object_name from dba_objects where rownum < 10001 ;
declare
cursor c1 is
   select id from emp where mod(id,2) = 0 ;
v_id  number := 1 ;
v_date DATE := '01-JAN-08';
begin
  for c2 in c1
  loop
      insert into leave values ( v_id, c2.id, v_date );
      v_id := v_id + 1;
      v_date := v_date + 1;
  end loop;
end;
-- Set autotrace
set autotrace traceonly explain
-- =================================
-- Outer join
-- =================================
select e.id, e.name, l.id, l.leave_date
from   emp e, leave l
where  e.id = l.emp_id (+) ;
-- ===================================
-- select in select to get same results as above outer join
-- ===================================
select e.id, e.name,
       (select l.id from leave l where l.emp_id = e.id ) leave_id,
       (select l.leave_date from leave l where l.emp_id = e.id ) leave_date
from   emp e ;My hidden question, how these two methods internally work? in the plan we can only see something like 'hash join right outer' or something like that. But how exactly outer join is executed? how is the result formed?
I have got following plans for the two methods
SQL> select e.id, e.name, l.id, l.leave_date
  2  from   emp e, leave l
  3  where  e.id = l.emp_id (+) ;
Elapsed: 00:00:00.03
Execution Plan
Plan hash value: 98076489
| Id  | Operation             | Name  | Rows  | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT      |       | 10000 |  5371K|    16   (7)| 00:00:01 |
|*  1 |  HASH JOIN RIGHT OUTER|       | 10000 |  5371K|    16   (7)| 00:00:01 |
|   2 |   TABLE ACCESS FULL   | LEAVE |  5012 |   171K|     6   (0)| 00:00:01 |
|   3 |   TABLE ACCESS FULL   | EMP   | 10000 |  5029K|     9   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   1 - access("E"."ID"="L"."EMP_ID"(+))
Note
   - dynamic sampling used for this statement
SQL> select e.id, e.name,
  2         (select l.id from leave l where l.emp_id = e.id ) leave_id,
  3         (select l.leave_date from leave l where l.emp_id = e.id ) leave_date
  4  from   emp e ;
Elapsed: 00:00:00.18
Execution Plan
Plan hash value: 2670217481
| Id  | Operation                   | Name        | Rows  | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT            |             | 10000 |  5029K|     9   (0)| 00:00:01 |
|   1 |  TABLE ACCESS BY INDEX ROWID| LEAVE       |    50 |  1300 |     2   (0)| 00:00:01 |
|*  2 |   INDEX RANGE SCAN          | LEAVE_IDX_1 |    20 |       |     1   (0)| 00:00:01 |
|   3 |  TABLE ACCESS BY INDEX ROWID| LEAVE       |    50 |  1100 |     2   (0)| 00:00:01 |
|*  4 |   INDEX RANGE SCAN          | LEAVE_IDX_1 |    20 |       |     1   (0)| 00:00:01 |
|   5 |  TABLE ACCESS FULL          | EMP         | 10000 |  5029K|     9   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   2 - access("L"."EMP_ID"=:B1)
   4 - access("L"."EMP_ID"=:B1)
Note
   - dynamic sampling used for this statementPlease let me know your thoughts.
Thanks in advance

Answer 1

A better indicator of performance would be to look at the number of consistent gets that are required to execute the query.
In my environment:
SQL> SELECT * FROM V$VERSION;
BANNER
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bi
PL/SQL Release 10.2.0.4.0 - Production
CORE    10.2.0.4.0      Production
TNS for 64-bit Windows: Version 10.2.0.4.0 - Production
NLSRTL Version 10.2.0.4.0 - Production
SQL> SHOW PARAMETER OPT
NAME                                 TYPE        VALUE
filesystemio_options                 string
object_cache_optimal_size            integer     102400
optimizer_dynamic_sampling           integer     2
optimizer_features_enable            string      10.2.0.4
optimizer_index_caching              integer     0
optimizer_index_cost_adj             integer     100
optimizer_mode                       string      ALL_ROWS
optimizer_secure_view_merging        boolean     TRUE
plsql_optimize_level                 integer     2The OUTER JOIN produced the following results:
SQL> select e.id, e.name, l.id, l.leave_date
  2  from   emp e, leave l
  3  where  e.id = l.emp_id (+) ;
10000 rows selected.
Execution Plan
Plan hash value: 98076489
| Id  | Operation             | Name  | Rows  | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT      |       | 10000 |   380K|     9  (12)| 00:00:01 |
|*  1 |  HASH JOIN RIGHT OUTER|       | 10000 |   380K|     9  (12)| 00:00:01 |
|   2 |   TABLE ACCESS FULL   | LEAVE |  5017 | 80272 |     3   (0)| 00:00:01 |
|   3 |   TABLE ACCESS FULL   | EMP   | 10000 |   224K|     5   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   1 - access("E"."ID"="L"."EMP_ID"(+))
Statistics
          0  recursive calls
          0  db block gets
        723  consistent gets
          0  physical reads
          0  redo size
     364047  bytes sent via SQL*Net to client
       7672  bytes received via SQL*Net from client
        668  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
      10000  rows processedThe inline subquery produced these results:
SQL> select e.id, e.name,
  2         (select l.id from leave l where l.emp_id = e.id ) leave_id,
  3         (select l.leave_date from leave l where l.emp_id = e.id ) leave_dat
  4  from   emp e ;
10000 rows selected.
Execution Plan
Plan hash value: 1706216391
| Id  | Operation         | Name  | Rows  | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT  |       | 10000 |   224K|     5   (0)| 00:00:01 |
|*  1 |  TABLE ACCESS FULL| LEAVE |     1 |     9 |     3   (0)| 00:00:01 |
|*  2 |  TABLE ACCESS FULL| LEAVE |     1 |    13 |     3   (0)| 00:00:01 |
|   3 |  TABLE ACCESS FULL| EMP   | 10000 |   224K|     5   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   1 - filter("L"."EMP_ID"=:B1)
   2 - filter("L"."EMP_ID"=:B1)
Statistics
          0  recursive calls
          0  db block gets
     360705  consistent gets
          0  physical reads
          0  redo size
     364053  bytes sent via SQL*Net to client
       7672  bytes received via SQL*Net from client
        668  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
      10000  rows processedSee the 723 consistent gets versus 360705? That is a huge difference.
The second method may be more viable if you create indexes on the columns in the leave table that you are joining to your EMP table.
For example:
SQL> CREATE INDEX LEAD_ID_IDX ON LEAVE(EMP_ID, ID, LEAVE_DATE);
Index created.
SQL> set autotrace traceonly
SQL> select e.id, e.name,
  2         (select l.id from leave l where l.emp_id = e.id ) leave_id,
  3         (select l.leave_date from leave l where l.emp_id = e.id ) leave_date
  4  from   emp e ;
10000 rows selected.
Execution Plan
Plan hash value: 1822800249
| Id  | Operation         | Name        | Rows  | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT  |             | 10000 |   224K|     5   (0)| 00:00:01 |
|*  1 |  INDEX RANGE SCAN | LEAD_ID_IDX |     1 |     9 |     2   (0)| 00:00:01 |
|*  2 |  INDEX RANGE SCAN | LEAD_ID_IDX |     1 |    13 |     2   (0)| 00:00:01 |
|   3 |  TABLE ACCESS FULL| EMP         | 10000 |   224K|     5   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   1 - access("L"."EMP_ID"=:B1)
   2 - access("L"."EMP_ID"=:B1)
Statistics
          1  recursive calls
          0  db block gets
      22111  consistent gets
         19  physical reads
          0  redo size
     364053  bytes sent via SQL*Net to client
       7672  bytes received via SQL*Net from client
        668  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
      10000  rows processedThe query improved by a more than a factor of 10 with the index but the consistent gets are still significantly higher then the OUTER JOIN query. Additionally I always try and take the approach when developing queries to minimize the number of table accesses possible. In your second place you have to access the LEAVE table twice, instead of once in the first query.