PostgreSQL^® Optimizer Bits: Join Removal

In der Serie „PostgreSQL^® Optimizer Bits“ werden Strategien und Besonderheiten des PostgreSQL^® Optimizers vorgestellt. Heute beschäftigt sich die Serie mit dem Feature Join Removal des Optimizers in der kommenden Version 9.0. Nachdem im letzten Beitrag unserer Serie Semi und Anti Joins besprochen wurden, setzen wir uns heute mit Join Removal auseinander. Join Removal ist eine Optimierungsstrategie des Optimizers, die Tabellen der rechten Seite in LEFT JOINs aus der Join-Evaluierung ausschließen kann, wenn keine Spalten aus dieser Tabelle in der Ergebnismenge qualifiziert wurden und die rechte Seite des LEFT JOINs eindeutig ist, so dass hierdurch keine weiteren Tupel hinzukommen. Dies macht auch erforderlich, dass mindestens ein UNIQUE CONSTRAINT existiert, der beide Seiten entsprechend eindeutig qualifiziert wie gefordert. Betrachten wir folgendes kleines Beispiel mit zwei Tabellen a und b, wobei b Detaildatensätze verknüpft mit a enthält.

EXPLAIN SELECT
   a.name
FROM
   a LEFT JOIN b ON (b.id = a.id)
WHERE
   a.name LIKE 'M%';

Diese Query selektiert aus einem LEFT JOIN den Namen einer Person aus der Relation a. Man erkennt schnell, dass der LEFT JOIN auf die Relation b in diesem Fall nutzlos ist, wenn die verknüpften Felder a.id und b.id eindeutig sind. In diesem Fall würde auch bei Auftreten eines verknüpften Tupels kein weiteres Tupel erzeugt werden. In PostgreSQL^® 8.4 wird dennoch der Join ausformuliert:

Nested Loop Left Join  (cost=0.00..9.33 rows=1 width=6)
   ->  Seq Scan on a  (cost=0.00..1.05 rows=1 width=10)
         Filter: (name ~~ 'M%'::text)
   ->  Index Scan using b_pkey on b  (cost=0.00..8.27 rows=1 width=4)
         Index Cond: (b.id = a.id)

In PostgreSQL^® 9.0alpha4 hingegen wird der Join eliminiert: dadurch vereinfacht sich der Plan wie folgt:

Seq Scan on b  (cost=0.00..1.05 rows=1 width=11) (actual time=0.012..0.013 rows=1 loops=1)
   Filter: (name ~~ 'M%'::text)
 Total runtime: 0.045 ms

Der Optimizer kann an dieser Stelle nur die linke Seite berücksichtigen und daher die Relation b komplett aus dem Join eliminieren. Interessant wird diese Optimierungsmöglichkeit bei Verknüpfungen mit vielen LEFT JOINs (bspw. a LEFT JOIN b LEFT JOIN c LEFT JOIN d ...), wo mehrere Relationen aufgrund der Zusammensetzung der Abfrage aus dem Join entfernt werden können. Dadurch verbessern sich auch die Möglichkeiten des Optimizers, der weniger Tabellen bei der Optimierung der Verknüpfungspfade berücksichtigen muss. Auch für Views ist diese Optimierungsmöglichkeit interessant, da nicht qualifizierte Spalten aus der zugrundeliegenden Definition des Views eliminiert werden und daher implizit zu derartigen Abfragen führen können. So weit zum aktuellen Artikel der Serie, der nächste wird bald folgen. Alle Blog-Artikel zum Thema PostgresQL werden auch als Kategorie PostgreSQL^® samt eigenem Feed angeboten – und falls ihr nach Support und Services für PostgreSQL^® sucht, seit ihr bei uns ebenfalls richtig.