You deduction is basically correct, but you must take in account than not every optimization that is possible is also implemented.
Oracle pragmatically observes the potential and decides where the optimization should be extended.
For example there were times where the predicate where 1=1 and ...
could confuse the optimizer, but as this "construction" is used rather often, in recent version the optimizer recognised it and ignore it without side effects.
Your setup of outer join to child, while selecting distinct
from the parent columns only is probably not very frequent and therefore not yet covered.
Here a similar example, where Oracle can skip a table from a view (Note the PK
and FK
definition, which is crutial)
create table employees (
employee_id int primary key,
employee_name varchar2(10),
employee_active varchar2(10));
create table employee_info (
employee_id int,
marital_status varchar2(10));
alter table employee_info
add constraint emp_info_fk1 foreign key (employee_id)
references employees (employee_id);
create or replace view employee_view as
select e.EMPLOYEE_ID, e.employee_name, e.employee_active, ei.marital_status
from employees e
join employee_info ei on ei.employee_id = e.employee_id;
The query select marital_status from employee_view where employee_id = 13
can skip the employees
(parent) table and access only the child table
-----------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-----------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 20 | 2 (0)| 00:00:01 |
|* 1 | TABLE ACCESS FULL| EMPLOYEE_INFO | 1 | 20 | 2 (0)| 00:00:01 |
-----------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter("EI"."EMPLOYEE_ID"=13)
More information and links in similar answer