Query parse and execution order

Question

Hi,
In the below SQL, I could understand that it would parse from Right to Left, first filter condition fieldname, Syntax is verified and then join column names.
From the below execution plan, I believe it executes from right to left, first filters the data and then joins the two tables, is this correct.
Is this in the fixed order or keep changing based on the statistics or any other parameter.
I would like to know how this SQL Select statement is executed in the run-time, whether data is joined first and then the filter condition is applied or
the other way round. Please give me more details on this, thank you.
SELECT * FROM EMP E, DEPT D
WHERE E.DEPTID = D.DEPTID AND
D.DEPTNAME = 'DEPT1';
Below is the execution plan,
SQL > SELECT * FROM EMP E, DEPT D
2 WHERE E.DEPTID = D.DEPTID AND
3 D.DEPTNAME = 'DEPT1';
Execution Plan
Plan hash value: 1123238657
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 143 | 5 (20)| 00:00:01 |
|* 1 | HASH JOIN | | 1 | 143 | 5 (20)| 00:00:01 |
| 2 | TABLE ACCESS FULL| EMP | 1 | 78 | 2 (0)| 00:00:01 |
|* 3 | TABLE ACCESS FULL| DEPT | 1 | 65 | 2 (0)| 00:00:01 |
Predicate Information (identified by operation id):
1 - access("E"."DEPTID"="D"."DEPTID")
3 - filter("D"."DEPTNAME"='DEPT1')
Note
- dynamic sampling used for this statement

Answer 1

>
- Oracle does the full table scan of EMP table and makes an in-memory hash table with DEPTID as the hash key
- DEPT table is being read; as Oracle reads DEPT table, applies the filter predicate ("D"."DEPTNAME"='DEPT1'), applies the hashing function to the join key (DEPTID)
and uses it to locate the matching row from EMP
- rows are returned to the client
>
I believe that is correct for this particular query and plan only because there is only one row in each table. If the tables had many more records then the smaller of the two tables would be chosen to create the hash table and the following should apply.
The DEPT table is the smaller of the two tables so Oracle would do a full table scan of DEPT to make the in-memory hash with DEPTID as the hash key.
Then the EMP table (the larger table) is scanned and the DEPTID value used to probe the hash table to find the matching record and then the other filter predicate ("D"."DEPTNAME"='DEPT1') used to eliminate rows.
See section 11.6.4 Hash Joins in the Performance Tuning Guide
>
Hash joins are used for joining large data sets. The optimizer uses the smaller of two tables or data sources to build a hash table on the join key in memory. It then scans the larger table, probing the hash table to find the joined rows.
This method is best used when the smaller table fits in available memory. The cost is then limited to a single read pass over the data for the two tables.
>
This example uses a copy of emp and dept with no primary key or constraints
SQL> SELECT * FROM EMP1 E, DEPT1 D
  2  WHERE E.DEPTNO = D.DEPTNO AND
  3  D.DNAME = 'RESEARCH';
Execution Plan
Plan hash value: 619452140
| Id  | Operation          | Name  | Rows  | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT   |       |     5 |   380 |     7  (15)| 00:00:01 |
|*  1 |  HASH JOIN         |       |     5 |   380 |     7  (15)| 00:00:01 |
|*  2 |   TABLE ACCESS FULL| DEPT1 |     1 |    30 |     3   (0)| 00:00:01 |
|   3 |   TABLE ACCESS FULL| EMP1  |    14 |   644 |     3   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   1 - access("E"."DEPTNO"="D"."DEPTNO")
   2 - filter("D"."DNAME"='RESEARCH')
Note
   - dynamic sampling used for this statement (level=2)