HASH JOIN und NOT EXISTS

Zwei entsprechende Threads im OTN-Forum haben Jonathan Lewis dazu veranlasst innerhalb von zwei Wochen zwei Artikel mit dem identischen Titel Not Exists zu veröffentlichen. Da der Herr Lewis in der Regel über ein sehr zuverlässiges Gedächtnis verfügt, nehme ich an, dass er das mit Absicht so gemacht hat - und dass es keinen unique constraint auf seinen Artikelüberschriften gibt... Hier ein paar Notizen zu den Artikeln:

• https://jonathanlewis.wordpress.com/2015/04/13/not-exists/: beschäftigt sich mit der Auswirkung eines no_unnest Hints in der korrelierten NOT EXISTS Subquery. Durch den Hint wird aus dem HASH JOIN eine Filter-Operation, bei der für jeden Ergebnis-Satz aus der ersten Tabelle eine Lookup-Query ausgeführt wird. Die Effektivität dieses Vorgehens hängt davon ab, ob das Scalar Subquery Caching die Anzahl der Lookups reduzieren kann. Mit passenden Indizes (und geeigneten NOT NULL Constraints) lässt sich die Effektivität des Cachings erhöhen.
• https://jonathanlewis.wordpress.com/2015/04/26/not-exists-2/: untersucht einen weiteren Fall, in dem der no_unnest Hint anscheinend eine positive Wirkung auf die Laufzeit eine NOT EXISTS Query hatte (jedenfalls laut Aussage des Fragestellers im Thread), bei der ein Self-Join Datensätze suchte, bei denen ein Spaltenwert Übereinstimmungen und ein anderer Spaltenwert Abweichungen lieferte (also: where w1.x = w2.x and w1.y <> w2.y). Dazu liefert der Herr Lewis ein recht detailliertes Modell, bei dem er die Anzahl der übereinstimmenden bzw. abweichenden Werte unterschiedlich definiert, um die Effektivität von HASH JOIN bzw. Filter-Query in Abhängigkeit von diesen Voraussetzungen zu bestimmen. Das Ergebnis lautet: 
• wenn es in der Build Table "lange Hash-Chains" gibt (also viele identische Werte bzw. Hash-Ergebnisse für die Join-Spalte aus der ersten Tabelle), dann erhöht das (erwartungsgemäß) den Aufwand für Probe-Operation für ein Element der zweiten Tabelle.
• wenn sich die "langen Hash-Chains" aus einer ungleichmäßigen Verteilung ergeben (Stichwort: skew), dann kann das dazu führen, dass der Optimizer nicht erkennt, dass der HASH JOIN nicht die beste Lösung für das vorliegende Problem ist.

In beiden Fällen dienen die zugehörigen OTN-Threads als Anlass für die Untersuchungen, aber wie üblich fehlen in den Threads ab einem bestimmten Punkt die Informationen die erforderlich wären, um die exakten Zusammenhänge der ursprünglichen Probleme zu bestimmen.