Einführung in die Analyse der Query-Performance

Lass mich mit einer echten Story starten. Stell dir vor, du bist Entwickler auf einer großen E-Commerce-Plattform. Alles läuft super, bis auf eine Kleinigkeit: Der Monatsverkaufsbericht lädt so langsam, dass deine User noch eine Bestellung machen können, bevor er fertig ist. Du bist genervt, dein Manager ist genervt, der PostgreSQL-Server kocht wie ein Wasserkocher – und das Ganze riecht nach Apokalypse. Jetzt stell dir vor, du könntest mit einem Schlag die Ursache finden und fixen.

Query-Performance-Analyse ist wie ein Gesundheitscheck für deinen PostgreSQL. Damit findest du „Engpässe“ (Schmerzpunkte) und kannst sie beheben, um das Nutzererlebnis zu verbessern und Systemressourcen zu sparen.

Wie laufen Queries eigentlich unter der Haube von PostgreSQL?

Wenn du eine simple Query schreibst wie:

SELECT * FROM products WHERE price > 100;

PostgreSQL springt nicht sofort los und holt die Daten. Erst wird deine Query analysiert, dann überlegt sich der Server, wie er sie am besten ausführt – und erst dann geht’s los.

Die wichtigsten Phasen bei der Query-Ausführung:

1. Parsing. PostgreSQL checkt deine Query auf Syntaxfehler und wandelt sie in eine Zwischenrepräsentation um.
2. Optimierung. Der Query-Optimizer schaut sich verschiedene Ausführungspläne an und sucht den „billigsten“ raus (also den, der am wenigsten Zeit und Ressourcen frisst).
3. Ausführung. Der Server arbeitet nach dem gewählten Plan und holt die Daten.

Was ist eigentlich ein „Engpass“?

Ein „Engpass“ ist der Teil einer Query, der alles andere ausbremst. Das kann ein Schritt sein, der plötzlich mega viel Zeit oder Ressourcen braucht. Zum Beispiel, wenn PostgreSQL statt eines schnellen Index-Looks ein Full Table Scan (Seq Scan) macht – dann wird die Query langsam. Oder wenn es viel mehr Daten gibt als gedacht und der Server ewig sortiert, joined oder filtert.

Genau solche Sachen nennt man Engpässe – und die solltest du als Erstes suchen und optimieren.

Tools zur Analyse der Query-Performance

PostgreSQL hat ein paar richtig starke Tools, mit denen du Query-Probleme aufspüren kannst:

1. EXPLAIN und EXPLAIN ANALYZE. Diese Befehle zeigen dir, wie PostgreSQL eine Query ausführen will – oder führen sie sogar aus, um echte Performance-Daten zu messen.

• EXPLAIN: Zeigt den Ausführungsplan der Query, ohne sie wirklich auszuführen.
• EXPLAIN ANALYZE: Führt die Query aus und zeigt den echten Ausführungsplan mit echten Zeitwerten.

Beispiel für EXPLAIN:

EXPLAIN SELECT * FROM products WHERE price > 100;

Ausgabe:

Seq Scan on products  (cost=0.00..35.50 rows=5 width=72)
  Filter: (price > 100)

Hier siehst du, dass die Query einen „Seq Scan“ macht – also einen Full Table Scan, was bei großen Tabellen nicht cool ist.

2. pg_stat_statements. Das ist eine zusätzliche Extension, die alle ausgeführten Queries trackt. Sie zeigt dir:

• Welche Queries auf dem Server laufen.
• Wie viel Zeit jede Query braucht.
• Wie viele Zeilen die Query zurückgibt und wie viele Ressourcen sie braucht.

Um pg_stat_statements zu aktivieren, musst du:

1. Die Extension aktivieren:

CREATE EXTENSION pg_stat_statements;

2. Die PostgreSQL-Konfiguration anpassen: In der Datei postgresql.conf füge hinzu:

   shared_preload_libraries = 'pg_stat_statements'
   pg_stat_statements.track = all

3. PostgreSQL neu starten.

Jetzt kannst du Queries analysieren:

SELECT * FROM pg_stat_statements ORDER BY total_time DESC LIMIT 5;

Das zeigt dir die 5 „schwersten“ Queries, sortiert nach der gesamten Ausführungszeit.

3. Logging von langsamen Queries. Du kannst PostgreSQL so einstellen, dass Queries, die zu lange brauchen (z.B. mehr als 1 Sekunde), ins Logfile geschrieben werden.

Dafür in postgresql.conf einstellen:

log_min_duration_statement = 1000  # Zeit in Millisekunden (1 Sekunde)

Jetzt werden langsame Queries ins PostgreSQL-Log geschrieben.

Wichtige Metriken für die Performance-Analyse

Wenn du die Performance von Queries analysierst, schau auf diese Key-Metriken:

1. Ausführungszeit. Das ist die wichtigste Zahl – wie lange braucht die Query? Je schneller, desto besser.
2. Anzahl der Zeilen. Wenn deine Query mehr Zeilen zurückgibt oder scannt als erwartet, kann das ein Problem sein.
3. Index-Nutzung. Wenn die Query eigentlich einen Index nutzen sollte, aber stattdessen einen Seq Scan macht, ist das ein Zeichen für Optimierungsbedarf.
4. Buffer und Disk-Operationen. Queries, die viel auf die Platte zugreifen, sind langsamer als solche, die aus dem RAM lesen.

Wie setzt man das Ganze in der Praxis ein?

Beispiel 1: Langsame Query

Du schreibst eine Query, um alle Produkte mit Preis über 100 zu holen:

SELECT * FROM products WHERE price > 100;

Du merkst, dass die Query zu lange braucht. Du nutzt EXPLAIN und siehst:

Seq Scan on products  (cost=0.00..35.50 rows=5 width=72)
  Filter: (price > 100)

Das Problem: Die Query macht einen Full Table Scan, weil es keinen Index auf der Spalte price gibt.

Lösung:

Erstelle einen Index:

CREATE INDEX idx_price ON products(price);

Jetzt nutzt die Query einen Index Scan:

Index Scan using idx_price on products  (cost=0.15..8.25 rows=5 width=72)
  Index Cond: (price > 100)

Beispiel 2: Langsame Queries mit pg_stat_statements finden

Mit diesem Befehl:

SELECT query, total_time, calls
FROM pg_stat_statements
ORDER BY total_time DESC
LIMIT 1;

Findest du eine Query, die besonders viel Zeit frisst. Du schaust sie dir mit EXPLAIN ANALYZE an, optimierst sie – und schon läuft sie schneller.

Wenn du EXPLAIN, pg_stat_statements und die anderen Tools einsetzt, werden deine Queries schneller und dein PostgreSQL-Server läuft wie ein Schweizer Uhrwerk. In der nächsten Vorlesung tauchen wir tiefer in die EXPLAIN-Parameter wie cost, rows und width ein, damit du Execution-Pläne wie ein offenes Buch lesen kannst.