Join Elimination

Ein paar Stichworte zum Thema Join Elimination, also der Möglichkeit, einen Tabellenzugriff aus einer Abfrage heraus zu kürzen. Zunächst einige Links:

• Why are some of the tables in my query missing from the plan? - der Blog der CBO-Entwickler liefert eine Einführung zum Thema. Darin findet sich ein kleines Code-Beispiel und eine Erläuterung zu den verschiedenen Formen der Join-Elimination:
• seit 10.2 gibt es die Primary Key-Foreign Key Table Elimination, bei der der CBO auf Tabellen-Zugriffe verzichtet, die aufgrund der definierten FK-Beziehungen redundant sind.
• mit 11.1 wurde die Outer Join Table Elimination eingeführt, die keine FK-Beziehungen benötigt, sondern nur einen UK-Constraint auf der Join-Column der äußeren Tabelle (also der, die um NULL-Sätze ergänzt wird). Diese kann dann aus der Query herausgenommen werden, wenn keine ihrer Spalten in der Select-Liste erscheint.
• zu den Einschränkungen des Features gehört, dass multi-column PK-/FK-Constraints nicht unterstützt werden.
• Join Elimination - von Christian Antognini:
• erklärt auch nochmal anhand eines Beispiels die Primary Key-Foreign Key Table Elimination.
• seit 11.2 gibt es die Möglichkeit der Elimination unnötiger Self-Joins, die über den PK definiert sind.
• Join Views, ROWIDs And Query Transformations von Randolf Geist:
• daraus hatte ich hier schon mal ein paar wichtige Punkte aufgelistet.

Allen Varianten der Join Elimination ist offenbar gemeinsam, dass sichergestellt sein muss, dass:

• keine Informationen aus der eliminierten Tabelle in der Select-Liste benötigt werden (das ist jetzt keine große Überraschung ...)
• der Join keine Veränderung der Ergebnismenge bewirken kann, also keine Vergrößerung durch 1:n-Beziehungen und keine Verkleinerung durch 1:0-Verknüpfungen. Dazu müssen die Werte der Join-Spalte in der zu eliminierenden Tabelle UNIQUE sein (durch PK- oder UK-Constraint). In diesen Kontext gehört auch das Konzept der "Key-Preserved Tables", die einen Zugriff über ROWID erlauben, das in Randolf Geists Artikel ausführlich erläutert wird.

Daraus ergibt sich dann auch, dass in der Regel nur die Parent-Tabellen aus hierarchischen Tabellenbeziehungen eliminiert werden können und dass die Tabelle mit der höchsten Granularität erhalten bleibt: beim Join einer Artikel-Dimensionstabelle mit einer Sortiments-Dimensionstabelle kann also nur die übergeordnete Sortiments-Dimension eliminiert werden - ein Ausschluss der Artikel-Dimension ist auch dann nicht möglich, wenn ein Zugriff nur distinkte Werte der Sortiments-Dimension benötigt.

Einige der Beispiele zum Feature sehen nach außergewöhnlich sinnlosem SQL aus - etwa der OUTER JOIN ohne Zugriff auf die über outer join verknüpfte Tabelle. Aber für generierten SQL-Code oder für Snowflake-Dimensionen im DWH-Kontext könnte es ganz nützlich sein.