IFFS und Filterprädikate

Diesmal habe ich den Titel nicht - wie üblich - aus mangelnder Sorgfalt, sondern mit Bedacht vage gewählt, um dem Eintrag nicht seine ohnehin schon bescheidene Pointe zu nehmen... Davon abgesehen ist mir der beschriebene Effekt bestimmt schon ziemlich häufig begegnet, ohne dass ich darüber nachgedacht hätte. Aber genug der Vorrede: heute habe ich in einem Execution Plan ungefähr Folgendes gesehen:

-- 11.2.0.1

explain plan for
select *
  from test
 where c = 1;

select * from table(dbms_xplan.display);

Plan hash value: 850129961

--------------------------------------------------------------------------------
| Id  | Operation            | Name    | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------
|   0 | SELECT STATEMENT     |         |  1000 | 38000 |    22   (0)| 00:00:01 |
|*  1 |  INDEX FAST FULL SCAN| PK_TEST |  1000 | 38000 |    22   (0)| 00:00:01 |
--------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter("C"=1)

Daraufhin habe ich einen Blick auf die Index-Spalten geworfen:

select column_name
     , column_position
  from user_ind_columns
 where index_name = 'PK_TEST';

COLUMN_NAME                    COLUMN_POSITION
------------------------------ ---------------
A                                            1

Anschließend habe ich mich einen Moment lang gewundert: ein IFFS mit einem Filterkriterium, das gar nicht im Index enthalten ist? Ein Blick auf die Objekt-Definition hat die Überraschung dann beendet - und auch ich spare mir hier jetzt die dramatische Steigerung:

create table test (
    a
  , b
  , c
  , constraint pk_test primary key(a)
) organization index
as
select rownum a
     , 'xxxxxxxxxx' b
     , mod(rownum, 10) c
  from dual
connect by level <= 10000

Es handelt sich also um eine IOT und deren Auftreten wird im Execution Plan offenbar immer als IFFS des PK-Index dargestellt, was durchaus einleuchtet, da das Index-Segment im Fall meiner Test-Tabelle ohne Overflow-Segment ja das einzige physikalische Objekt ist, auf das man sich beziehen kann. Und somit ist dann auch die Filteroperation einleuchtend, da das Index-Segment natürlich alle Tabellen-Attributen enthält - nur die Spaltenangabe der user_ind_columns passt nicht ganz zu den anderen Informationen. Da aber auch nur die PK-Spalte A im Beispiel als access-Prädikat verwendet werden kann, bin ich auch mit dieser Klassifizierung zufrieden.