What really makes the FILTER operation unavoidable is the NO_UNNEST hint isn’t it? It dictates that the subquery gets executed as is for every row from the parent – hence the filter.

At a fairly low level what you’re describing is the difference between:

call function A, then call function B with the result of A
and
call function A, which calls function B

I don’t really think there’s going to be a significant difference whichever option you choose (although there may be some interesting ramifications in parallel queries) – but whichever action is chosen I think the plan could still be written to show the FILTER operation as a separate operation simply for clarity of view. (Remember, as I pointed out to Henish, execution plans don’t, and probably can’t, show us a perfect representation of what’s going on.)

I think you just have to decide that the execution plan can’t always be a perfect description of everything that’s happening.

The “sort aggregate” has to be there because there’s a max() in the subquery – even though the optimizer knows there will be only one row because of the “first row” and knows it won’t need to sort that one row. The oddity is just a side-effect of the min/max method.

--------------------------------------------------------------------------
| Id  | Operation                      | Name    | Rows  | Bytes | Cost  |  
--------------------------------------------------------------------------  
|   0 | SELECT STATEMENT               |         |     1 |    19 |     4 |  
|   1 |  TABLE ACCESS BY INDEX ROWID   | MIN_MAX |     1 |    19 |     2 |  
|*  2 |   INDEX UNIQUE SCAN            | MM_PK   |     1 |       |     1 |  
|   3 |    SORT AGGREGATE              |         |     1 |     8 |       |  
|   4 |     FIRST ROW                  |         |    10 |    80 |     2 |  
|*  5 |      INDEX RANGE SCAN (MIN/MAX)| MM_PK   |    10 |    80 |     2 |  
--------------------------------------------------------------------------  
  
Predicate Information (identified by operation id):  
---------------------------------------------------  
2 - access("MM1"."ID_PARENT"=100 AND "MM1"."ID_CHILD"= (SELECT  
MAX("MM2"."ID_CHILD") FROM "MIN_MAX" "MM2" WHERE "MM2"."ID_PARENT"=100))  
5 - access("MM2"."ID_PARENT"=100) 

in the above plan will sort happen first and get the first row? than why first row come before sort aggregate if we read plan from bottom up?

OR

will oracle stop scaning when it read value >100 and return the last value for id_child if my assumption is correct for index mm_pk define as (id_parent, id_child)?

Thanks

Can you please explain why your “ideal” plan is better than the original plan?
My understanding is the ideal plan will range scan the index and provide the rows to the next step which will filter them based on subquery. But the original plan will apply subquery filter and access predicate to the range scan, thereby filtering rows early. Or am I misunderstood on how “access” and “filter” predicates are applied?