FTS Kosten bei I/O costing in 11.2

Ein guter Datenbank-Fachmann sollte ein gutes Gedächtnis haben und strukturiert vorgehen. Leider ist mein Gedächtnis dieser Tage eher siebartig und meinem Vorgehen mangelt's an Ordnung. Deshalb komme ich auch erst jetzt auf die Idee, zu prüfen, wie sich die Dinge in 11.2.0.1 verhalten, die Jonathan Lewis in seinem cbo Buch für Releases bis 10.1.0.4 untersucht hatte.

FTS bei I/O costing
Fangen wir an mit dem FTS bei I/O costing (S.11):

-- entspricht dem Beispiel auf S.10 des cbo Buchs
create table t1 tablespace test_ts
pctfree 99
pctused 1
as
select rownum id
     , trunc(100 * dbms_random.normal) val
  , rpad('x', 100) padding
  from all_objects
 where rownum <= 10000;

exec dbms_stats.gather_table_stats(user, 'T1', estimate_percent => 100)

select /*+ opt_param('_optimizer_cost_model','io') */ max(val)
  from t1;

-----------------------------------------------------------
| Id  | Operation          | Name | Rows  | Bytes | Cost  |
-----------------------------------------------------------
|   0 | SELECT STATEMENT   |      |     1 |     4 |  1519 |
|   1 |  SORT AGGREGATE    |      |     1 |     4 |       |
|   2 |   TABLE ACCESS FULL| T1   | 10000 | 40000 |  1519 |
-----------------------------------------------------------

Bei Jonathan Lewis ist das Ergebnis 1518, was möglicherweise einmal mehr ein Effekt der Verwendung von Rundung bzw. Ceil-Funktion ist. Ich sehe gerade, dass Randolf Geist explizit ein

alter session set "_table_scan_cost_plus_one" = false;

in seinen - sehr ähnlich definierten - Test eingebaut hat, um die Formel zu überprüfen. Außerdem sehe ich, dass er statt des opt_param-Hints den klareren Hint nocpu_costing verwendet hat - und ohnehin schon alles gemacht hat, was ich hier ausprobiere - aber das soll mich nicht aufhalten... Mit _table_scan_cost_plus_one=false komme ich jedenfalls auch auf die erwartete 1518.