Thanks for the description – its a very useful insight into the way we should think about interpreting execution plans. It raises a couple of question, though, most significantly: Is there anything in, or that could be added to, the plan table that could allow an automatic analysis of the plan table to show that the subquery at line 5 was going to run first without having to do a semantic analysis of the filter predicate on line 1 ? As it stands I can infer that line 5 will execute before line 2 – but only because I can work out that line 5 represents what I called a “constant subquery” – but I can’t think of any way to analyze the plan table to make that inference within an SQL or PL/SQL script.

I’d be prepared to bet that if you ran this plan through OEM and displayed the pages that shows the execution plan for a query with the column showing order of operation, the ordering would be wrong because the code to calculate the order uses (or seems to use) the traditional “first child first” model, and it would be nice if OEM could get these things right.

The oddity in those plans (where the hash join swaps the join input) is that the order in which the tables are joined is not the order in which they appear in the plan. The order in which the operations run is still (except for certain parallel plans) the order you would expect from the “traditional” descent through the plan.

so really the execution is :
Initialize FILTER in step 1. if filter can be resolved completely then it is done. if it has a dependency then resolve it and then proceed with next step.
The dependency in this case is the subquery in step 5.
The join in step 3 is not initialized until the step 5 is resolved at least once.
Step 5 is initialized and resolved and returns execution to step 1.
Since all dependencies of 1 are resolved then it can proceed but since the results of step 5 does not match the criteria then it stops.