It’s always worth coming up with a small collections of hypotheses to explain an anomaly. The trick is then to think up the simplest test that would eliminate some of those hypotheses.

In your case a couple of quick checks would be:
a) Does the (estimated) cost of a tablescan change from 10g to 11g
b) Is there any difference in the more complex case when tested against 10g rather than 11g.

If you’re thinking about the case in the previous comment, there’s also a related question about direct path reads for tablescans – if you’re going to do an update you (probably) have to do it in the buffer cache, would this automatically ensure that Oracle won’t read to the PGA for the tablescan.

My humble thinking is we are compare different execution paths, in update, to apply rownum <= 200 result from table has to be materialized. more like in

select *
from (select rownum ….)

My thinking here is, with oracle 11g since full table scans are done in PGA the cost of materialization has gone done and its a valid plan.

Thanks
Amir Riaz

update /*+gather_plan_statistics*/ t1 set     small_vc =
upper(small_vc) where     id > 100

Plan hash value: 2927627013

----------------------------------------------------------------------------------------------
| Id  | Operation          | Name | Starts | E-Rows | A-Rows |   A-Time   | Buffers | Reads  |
----------------------------------------------------------------------------------------------
|   0 | UPDATE STATEMENT   |      |      1 |        |      0 |00:00:00.11 |     469 |    172 |
|   1 |  UPDATE            | T1   |      1 |        |      0 |00:00:00.11 |     469 |    172 |
|*  2 |   TABLE ACCESS FULL| T1   |      1 |   9901 |   9900 |00:00:01.11 |     174 |    171 |
----------------------------------------------------------------------------------------------

but if CBO is forced to use the index then the LIO statistic is better

update /*+gather_plan_statistics index(t1,t1_i1)*/t1 set     small_vc =
upper(small_vc) where     id > 100

Plan hash value: 3664600488

----------------------------------------------------------------------------------------------
| Id  | Operation         | Name  | Starts | E-Rows | A-Rows |   A-Time   | Buffers | Reads  |
----------------------------------------------------------------------------------------------
|   0 | UPDATE STATEMENT  |       |      1 |        |      0 |00:00:00.07 |     319 |     22 |
|   1 |  UPDATE           | T1    |      1 |        |      0 |00:00:00.07 |     319 |     22 |
|*  2 |   INDEX RANGE SCAN| T1_I1 |      1 |   9901 |   9900 |00:00:00.01 |      22 |     22 |
----------------------------------------------------------------------------------------------

One of those “obvious in retrospect” things. I wonder how many people expect some online inquiry with a sort to work first rows?

I think the intent in the original code was to avoid having to handle a very large array from the “returning” clause – with the assumption that the limit wouldn’t impose a significant overhead if they had to handle a small number of batches

Correct guess – I think there’s even a little note somewhere in the documentation (though I don’t recall where) that inserts, updates and deletes alway run all_rows and the hint is illegal in these cases.

Cheers,
Flado