Kategorien:	credativ® Inside

Wer PostgreSQL®-Abfragen optimieren möchte, kommt an zwei Befehlen nicht vorbei: EXPLAIN und EXPLAIN ANALYZE. Beide liefern Einblicke in den sogenannten Query Plan, also den Plan, den PostgreSQL® intern erstellt, um eine Abfrage auszuführen. Doch obwohl die Namen ähnlich klingen, unterscheiden sie sich grundlegend darin, was sie messen und wann man sie sinnvoll einsetzt.

Dieser Artikel führt Sie Schritt für Schritt durch das Thema: von der Frage, wie PostgreSQL® überhaupt einen Ausführungsplan erstellt, über die konkreten Unterschiede zwischen beiden Befehlen bis hin zu häufigen Fehlinterpretationen und praktischen Entscheidungshilfen. Am Ende wissen Sie genau, welches Werkzeug in welcher Situation das richtige ist.

Was macht PostgreSQL® mit einer Abfrage vor der Ausführung?

Bevor PostgreSQL® eine SQL-Abfrage tatsächlich ausführt, durchläuft sie intern mehrere Verarbeitungsschritte. Der sogenannte Query Planner analysiert die Abfrage, berücksichtigt verfügbare Indizes, Tabellenstatistiken und Kostenschätzungen und entscheidet dann, auf welchem Weg das Ergebnis am effizientesten ermittelt werden kann.

Das Ergebnis dieses Prozesses ist der Query Plan: eine baumartige Struktur, die zeigt, welche Operationen in welcher Reihenfolge ausgeführt werden. Typische Operationen sind Sequential Scans (zeilenweises Durchlesen einer Tabelle), Index Scans, Hash Joins oder Merge Joins. Jede dieser Operationen hat ihren eigenen Platz im Baum und ihre eigene Kostenschätzung.

Ein gutes Verständnis dieses Planungsprozesses ist die Grundlage für jede PostgreSQL-Abfrageoptimierung. Denn nur wer versteht, wie der Planner denkt, kann gezielt eingreifen, wenn ein Plan suboptimal ist.

Was EXPLAIN zeigt – und was es verschweigt

EXPLAIN gibt den Ausführungsplan einer Abfrage aus, ohne diese tatsächlich auszuführen. Der Befehl zeigt, was PostgreSQL® plant zu tun, nicht, was es getan hat.

Die Ausgabe enthält für jeden Knoten im Planbaum drei wichtige Angaben:

Cost: Eine geschätzte Kosteneinheit, aufgeteilt in Startkosten und Gesamtkosten. Diese Zahl ist relativ und dient dem Vergleich verschiedener Planoptionen.
Rows: Die geschätzte Anzahl der zurückgelieferten Zeilen.
Width: Die geschätzte durchschnittliche Zeilengröße in Bytes.

Das Entscheidende: Alle diese Werte sind Schätzungen, die auf Tabellenstatistiken basieren. EXPLAIN führt die Abfrage nicht aus und misst keine echten Laufzeiten. Wenn die Statistiken veraltet sind oder die Datenverteilung ungewöhnlich ist, können die Schätzungen erheblich von der Realität abweichen. EXPLAIN zeigt also den geplanten Weg, aber nicht, wie lange dieser Weg tatsächlich dauert.

Wie EXPLAIN ANALYZE echte Laufzeitdaten liefert

Aufbauend auf dem, was EXPLAIN liefert, geht EXPLAIN ANALYZE einen entscheidenden Schritt weiter: Die Abfrage wird tatsächlich ausgeführt, und die gemessenen Laufzeitdaten werden dem Plan gegenübergestellt.

Zusätzlich zu den Schätzwerten aus EXPLAIN liefert EXPLAIN ANALYZE für jeden Planknoten:

Actual Time: Die tatsächlich gemessene Ausführungszeit in Millisekunden, aufgeteilt in Startzeit und Gesamtzeit.
Actual Rows: Die tatsächliche Anzahl der verarbeiteten Zeilen.
Loops: Wie oft ein Knoten wiederholt ausgeführt wurde, zum Beispiel bei Nested Loops.

Besonders aufschlussreich ist der direkte Vergleich zwischen den geschätzten und den tatsächlichen Zeilenzahlen. Weicht zum Beispiel die geschätzte Zeilenzahl von 100 stark von der tatsächlichen Zahl von 50.000 ab, ist das ein klares Signal, dass die Statistiken veraltet sind und ein ANALYZE auf die betroffene Tabelle sinnvoll wäre. Für eine tiefgehende PostgreSQL-Performance-Analyse ist EXPLAIN ANALYZE daher das deutlich mächtigere Werkzeug.

EXPLAIN ANALYZE sicher und gezielt einsetzen

Da EXPLAIN ANALYZE die Abfrage wirklich ausführt, sind einige Punkte beim Einsatz zu beachten. Besonders bei schreibenden Operationen wie INSERT, UPDATE oder DELETE verändert der Befehl tatsächlich Daten in der Datenbank.

Um das zu vermeiden, empfiehlt sich folgendes Vorgehen:

Schreibende Abfragen in einer Transaktion kapseln und am Ende ein ROLLBACK ausführen, sodass keine Änderungen dauerhaft gespeichert werden.
Für noch detailliertere Informationen die Optionen BUFFERS und FORMAT JSON ergänzen. BUFFERS zeigt, wie viele Datenblöcke aus dem Cache gelesen oder von der Festplatte geholt wurden.
Die Abfrage möglichst unter realistischen Bedingungen analysieren, also mit einem ähnlichen Datenbankzustand wie in der Produktion.

Ein typischer, sicherer Aufruf für eine schreibende Abfrage sieht so aus: BEGIN; EXPLAIN ANALYZE UPDATE ...; ROLLBACK;. So erhalten Sie die Laufzeitdaten, ohne Produktionsdaten zu verändern.

Häufige Fehlinterpretationen der EXPLAIN-Ausgabe

Auch erfahrene Entwickler stolpern bei der Interpretation von EXPLAIN-Ausgaben über dieselben Fallen. Hier sind die häufigsten Missverständnisse, die es zu vermeiden gilt.

Hohe Cost bedeutet nicht automatisch schlechte Performance

Die Cost-Werte in PostgreSQL® sind relative Einheiten, keine Millisekunden. Ein Sequential Scan mit einer Cost von 5000 kann schneller sein als ein Index Scan mit einer Cost von 200, wenn die Tabelle vollständig im Shared Buffer liegt. Die Kosten dienen dem Planner als Entscheidungshilfe, sind aber kein direktes Maß für die Ausführungszeit.

Ein Index wird nicht genutzt? Das muss kein Fehler sein

Viele gehen davon aus, dass ein vorhandener Index immer genutzt werden sollte. PostgreSQL® entscheidet sich jedoch bewusst gegen einen Index, wenn der Planner erwartet, dass ein Sequential Scan effizienter ist, zum Beispiel wenn ein großer Teil der Tabelle zurückgegeben wird. Das ist kein Bug, sondern beabsichtigtes Verhalten.

Geschätzte und tatsächliche Zeilenzahlen vergleichen

Nur EXPLAIN ANALYZE liefert beide Werte. Weichen sie stark voneinander ab, lohnt es sich, Tabellenstatistiken mit ANALYZE zu aktualisieren oder den Statistikzielwert für bestimmte Spalten anzupassen.

Wann EXPLAIN reicht – und wann ANALYZE sein muss

Die Entscheidung zwischen beiden Befehlen hängt von der Situation und dem Ziel der Analyse ab. Als Faustregel gilt:

EXPLAIN genügt, wenn Sie schnell prüfen möchten, ob PostgreSQL® den richtigen Plan wählt, einen Index berücksichtigt oder einen Join korrekt auflöst. Da die Abfrage nicht ausgeführt wird, ist es auch auf Produktionssystemen jederzeit sicher einsetzbar.
EXPLAIN ANALYZE ist notwendig, wenn Sie tatsächliche Laufzeiten messen, Schätzungen mit der Realität vergleichen oder einen konkreten Performance-Engpass lokalisieren möchten. Hier liefert nur die echte Ausführung verlässliche Daten.

Für die Datenbankoptimierung im Alltag empfiehlt sich ein zweistufiger Ansatz: Zuerst mit EXPLAIN den Plan verstehen und grobe Probleme erkennen, dann mit EXPLAIN ANALYZE die tatsächlichen Laufzeiten messen und Schätzfehler aufdecken. Wer beide Werkzeuge kombiniert, hat ein vollständiges Bild des Abfrageverhaltens und kann gezielt optimieren. Weitere Informationen zu PostgreSQL-Optimierungsservices finden Sie in unserem Portfolio.

Wie credativ® bei der PostgreSQL®-Abfrageoptimierung unterstützt

Das Interpretieren von Query Plans und das gezielte Tuning von PostgreSQL®-Abfragen erfordert tiefes Datenbankwissen und praktische Erfahrung. Genau hier setzen wir an: Unser PostgreSQL® Competence Center begleitet Unternehmen bei allen Fragen rund um Performance, Betrieb und Weiterentwicklung ihrer PostgreSQL®-Umgebungen.

Konkret unterstützen wir Sie unter anderem bei:

Analyse und Optimierung langsamer Abfragen mit EXPLAIN ANALYZE und ergänzenden Werkzeugen
Aufbau und Konfiguration maßgeschneiderter Monitoring-Umgebungen zur frühzeitigen Erkennung von Performance-Problemen
Tuning von Datenbankparametern, Indizes und Tabellenstatistiken
High Availability, Clustern und Replikation für produktionskritische PostgreSQL®-Umgebungen
Individuelle Workshops und Schulungen, damit Ihr Team die richtigen Werkzeuge selbst sicher einsetzen kann

Ob einmalige Unterstützung bei einem konkreten Performance-Problem oder langfristige Begleitung Ihrer gesamten PostgreSQL®-Infrastruktur: Wir stehen Ihnen mit direktem Zugang zu erfahrenen Spezialisten zur Seite, ohne Callcenter und ohne Umwege. Kontaktieren Sie uns und erfahren Sie, wie wir gemeinsam das Beste aus Ihrer Datenbankumgebung herausholen.

Transparenzhinweis: PostgreSQL® ist eine Marke der PostgreSQL Community Association of Canada. credativ® ist Competence Center für PostgreSQL®. Die Nennung dient ausschließlich der sachlichen Beschreibung von Dienstleistungen von credativ®.

PostgreSQL EXPLAIN vs. EXPLAIN ANALYZE: Was ist der Unterschied?