Fehlerhaftes Costing für Index Hash Joins

Jonathan Lewis zeigt in seinem Blog, dass die Kostenberechnung für Index Hash Joins in allen aktuellen Oracle-Releases massive Fehler enthält, was zur Folge haben kann, dass diese - in manchen Fällen sehr effiziente - Zugriffsoption nicht in Betracht gezogen wird: "This means the optimizer may be missing opportunities where the index hash join is a good execution path. Keep an eye open for this, you may want to hint some of your SQL (and then switch the hints into SQL Baselines, if you’re running 11g)." Ein Aspekt dabei ist, dass Indizes anhand ihrer Benamung ausgewählt werden, ein anderer, dass die Kosten der Einzelschritte nicht sinnvoll summiert werden; außerdem werden für den Index Join zusätzlich zu den erwarteten Kosten eines Index Fast Full Scan  noch die Kosten eines Index Full Scan aufgeschlagen, was inhaltlich nicht einleuchtet (und offenbar erst im 10053er Trace sichtbar wird).

Ich wollte mir noch eine passende Begriffsbestimmung für den Index Hash Join ausdenken, aber die findet man natürlich auch schon beim Herrn Lewis:

One of the less well known access paths available to the optimizer is the “index join” also known as the “index hash join” path. It’s an access path that can be used when the optimizer decides that it doesn’t need to visit a table to supply the select list because there are indexes on the table that, between them, hold all the required columns.

Und der Vollständigkeit halber dann auch noch ein dritter Link zum Scratchpad, diesmal auf ein Fallbeispiel, in dem eine Tabelle mehrfach referenziert wird, um den cbo auf die Idee zu bringen, für jeden Fall den geeigneten Index zu verwenden.

Hier angekommen erinnere ich mich daran, dass ich schon mal auf einen der Index-Join-Artikel verwiesen hatte - und da das dann bereits Teil 4 einer Serie war, ist es vermutlich einfacher gleich auf die entsprechende Kategorie im Scratchpad zu verweisen, die aktuell fünf Artikel enthält.