Nested Loops Optimierung in 11g

Coskan Gundogar schreibt in seinem Blog über Veränderungen im Verhalten von Nested Loops Operationen, die sich in 11g ergeben haben und die die Lesbarkeit von NL-Operationen beeinträchtigen: statt einer simplen Verknüpfung der äußeren Tabelle an die innere, deren Sätze dabei via Index eingelesen werden, wird jetzt die äußere Tabelle mit dem Index der inneren Tabelle über NL verknüpft und das Ergebnis dieser Operation wird dann in einem zweiten NL an die innere Tabelle geknüpft. Der Herr Gundogar ist mit dem Ergebnis nicht recht zufrieden, da es sich zwar angeblich um eine Performance-Optimierung handelt, davon in seinen Testergebnissen aber nichts zu sehen ist. Ich frage mich, ob es sich vielleicht nur um eine andere Visualisierung der Operation durch dbms_xplan handeln könnte, da in beiden Fällen die gleiche Arbeit anzufallen scheint.

Nachtrag 06.04.2011: ein Blick in die Doku beantwortet meine abschließende Überlegung negativ:

Oracle Database 11g Release 1 (11.1) introduces a new implementation for nested loop joins to reduce overall latency for physical I/O. When an index or a table block is not in the buffer cache and is needed to process the join, a physical I/O is required. In Oracle Database 11g Release 1 (11.1), Oracle Database can batch multiple physical I/O requests and process them using a vector I/O instead of processing them one at a time. As part of the new implementation for nested loop joins, two NESTED LOOPS join row sources might appear in the execution plan where only one would have appeared in prior releases. In such cases, Oracle Database allocates one NESTED LOOPS join row source to join the values from the table on the outer side of the join with the index on the inner side. A second row source is allocated to join the result of the first join, which includes the rowids stored in the index, with the table on the inner side of the join.

Also offenbar doch eine inhaltliche Änderung. Den Link habe ich übrigens bei Timur Akhmadeev entdeckt, der darauf hinweist, dass diese Implementierungsänderung auch Einfluß auf Sortierungen haben kann.

Nachtrag 21.08.2011: in einem Kommentar zum Blog von Coskan Gundogar weist Randolf Geist darauf hin, dass row source statistics sampling die Verwendung von Vector bzw. Batched I/O deaktiviert - was so ziemlich alle Trace-Operationen betrifft (Gather_Plan_Statistics Hint, STATISTICS_LEVEL=ALL, SQL_Trace). Wenn sie wirksam wird (was über die “Batched IO%” session statistics überprüfbar ist), kann die Optimierung offenbar recht deutliche Verbesserungen bewirken. (Ähnliches schreibt der Herr Geist auch in seinen aktuellen Blog-Artikeln zum Thema "Logical I/O")