Why update with subqueries does not have cost and cardinality?

Question

There is update.
update test t1 set dummy = (select dummy from test2 t2 where t1.id = t2.id);Both tables which have actual statistics. Each has 1000 rows. And column ID have values from 1 to 1000 in each table.
This is explain plan
| Id  | Operation          | Name  | Rows  | Bytes | Cost (%CPU)| Time     |
|   0 | UPDATE STATEMENT   |       |  1000 | 13000 |   426   (9)| 00:00:01 |
|   1 |  UPDATE            | TEST  |       |       |            |          |
|   2 |   TABLE ACCESS FULL| TEST  |  1000 | 13000 |   426   (9)| 00:00:01 |
|*  3 |   TABLE ACCESS FULL| TEST2 |     1 |    13 |   426   (9)| 00:00:01 |
Predicate Information (identified by operation id):
   3 - filter("T2"."ID"=:B1)We can see here, that Oracle consider subquery within update as once-executed subquery.
This is runtime plan
| Id  | Operation          | Name  | Starts | E-Rows | A-Rows |
|   1 |  UPDATE            | TEST  |      1 |        |      0 |
|   2 |   TABLE ACCESS FULL| TEST  |      1 |   1000 |   1000 |
|*  3 |   TABLE ACCESS FULL| TEST2 |   1000 |      1 |   1000 |
Predicate Information (identified by operation id):
   3 - filter("T2"."ID"=:B1)Why first plan does not have cost in step 1?
Does Oracle always not understand that update with subqueries will performed as NL or filter? In other words that step 3 will executed many times.
Or it is my bug (or what?)?

Answer 1

793769 wrote:
Does Oracle always not understand that update with subqueries will performed as NL or filter? In other words that step 3 will executed many times.
Or it is my bug (or what?)?It's not possible to say whether this is a bug or a deliberate choice.
Because of "subquery caching" (see http://jonathanlewis.wordpress.com/2006/11/06/filter-subqueries/ ) the optimizer cannot predict how often the subquery will have to run. So possibly it shows nothing rather than showing the best or worst cases or a pure guess.
Regards
Jonathan Lewis