PostgreSQL Performance-Tuning — Seminar für DBAs und Entwickler

Kurz gefasst — Warum ist die Abfrage langsam, warum wächst die Tabelle, obwohl nichts dazukommt, und welche der zweihundert Konfigurationsschrauben ist die richtige? Drei Tage an den Eigenheiten, die PostgreSQL von anderen Systemen unterscheidet — mit Messung statt Vermutung.

Für wen ist dieses Seminar

Datenbankadministratoren, die eine PostgreSQL-Instanz unter Last betreuen und wissen wollen, warum sie sich so verhält, wie sie sich verhält. Entwickler, deren Abfragen im Testsystem schnell und in der Produktion langsam sind. Systemarchitekten, die entscheiden müssen, ob mehr Arbeitsspeicher, ein anderer Index oder ein anderes Datenmodell die Antwort ist.

Wer aus einer anderen Datenbankwelt kommt — SQL Server, Oracle — findet hier die Stellen, an denen das erlernte Wissen in PostgreSQL nicht trägt: MVCC statt Sperren beim Lesen, Autovacuum statt Aufräumen im Hintergrund, ein Planer, der sich nicht überstimmen lässt.

Das Angebot richtet sich an Unternehmen, Behörden und Selbstständige.

Was du mitbringen solltest

Sicheres SQL und praktische Erfahrung mit PostgreSQL im Betrieb oder in der Entwicklung. Du solltest eine Datenbank angelegt, Abfragen geschrieben und schon einmal einen Index erstellt haben.

Nicht vorausgesetzt werden Kenntnisse über den Planer, über Vacuum oder über die Konfigurationsdatei. Wer die Grundlagen des Betriebs sucht — Installation, Benutzer, Sicherung —, ist in PostgreSQL Administration besser aufgehoben; die beiden ergänzen sich.

Inhalte im Überblick

Wie PostgreSQL an einen Plan kommt

• Ausführungspläne lesen: EXPLAIN (ANALYZE, BUFFERS) und was die Zahlen bedeuten
• Geschätzte gegen tatsächliche Zeilenzahl — die wichtigste Abweichung im Plan
• Statistiken: ANALYZE, default_statistics_target, wann Stichproben nicht reichen
• Erweiterte Statistiken mit CREATE STATISTICS bei abhängigen Spalten
• Parallel Query: wann er greift, wann er ausbleibt, was er kostet
• Wann JIT-Kompilierung hilft — und wann sie nur Zeit verbrennt

MVCC, Bloat und Autovacuum

• Tupel-Versionen, xmin/xmax: warum ein UPDATE eine neue Zeile schreibt
• Wie aus normalem Betrieb Bloat entsteht und woran man ihn misst
• Autovacuum: Schwellwerte, Kostenbremse, warum er zu spät kommt
• VACUUM, VACUUM FULL, REINDEX und CLUSTER — was jeweils wirklich passiert
• Freeze und Transaktions-Wraparound: die Warnung, die man nicht ignorieren darf
• HOT-Updates und fillfactor: Bloat vermeiden statt aufräumen

Indexe jenseits von B-Tree

• Wann B-Tree die richtige Wahl ist — und wann nicht
• GIN für Volltext, JSONB und Arrays
• GiST und SP-GiST für Bereiche und Geodaten
• BRIN für große, natürlich sortierte Tabellen
• Partielle Indexe, Ausdrucks-Indexe, INCLUDE-Spalten
• Index-Only-Scans und die Rolle der Visibility Map
• Ungenutzte, doppelte und aufgeblähte Indexe finden und entfernen

Arbeitsspeicher und Konfiguration

• shared_buffers und der Dateicache des Betriebssystems — warum eine Seite zweimal im Speicher liegt
• work_mem und hash_mem_multiplier: wann eine Sortierung auf die Platte ausweicht und was das kostet
• effective_cache_size als Hinweis an den Planer, nicht als Reservierung
• WAL und Checkpoints: max_wal_size, checkpoint_completion_target, Schreibspitzen glätten
• Welche Parameter wirklich wirken — und welche aus alten Anleitungen stammen

Nebenläufigkeit unter Last

• Sperren sichtbar machen: pg_locks, blockierende Abfragen finden
• Warteschlangen ohne Stau: FOR UPDATE SKIP LOCKED
• Advisory Locks für anwendungsseitige Koordination
• Verbindungen sind teuer: das Prozessmodell und warum ein Pooler dazugehört

Große Tabellen

• Deklarative Partitionierung: nach Bereich, Liste, Hash
• Partition Pruning — wann es greift und wann nicht
• Wartung partitionierter Tabellen, Partitionen anlegen und abhängen

Messen im laufenden Betrieb

• pg_stat_statements: die teuersten Abfragen finden, nicht die auffälligsten
• auto_explain für das, was nur in der Produktion passiert
• Die pg_stat_*-Sichten: Cache-Trefferquote, Sequential Scans, Index-Nutzung
• Ein Vorgehen, das reproduzierbar ist: messen, ändern, gegenmessen

Dauer: 3 Tage

Hinweis: Schwerpunkte und Tiefe passen wir bei Inhouse-Seminaren an euren Bestand an. Die obige Gliederung ist der geplante Standard-Aufbau des offenen Seminars.

Was du danach kannst

• Einen Ausführungsplan lesen und den Knoten benennen, an dem die geschätzte von der tatsächlichen Zeilenzahl abweicht — die Stelle, an der das Tuning beginnt
• Bloat an einer Tabelle messen und entscheiden, ob Autovacuum falsch eingestellt ist oder die Last das Problem ist
• Für eine gegebene Abfrage den passenden Indextyp wählen und begründen, warum B-Tree hier nicht die beste Wahl ist
• Erkennen, wann eine Sortierung auf die Platte ausweicht, und work_mem mit einer Zahl statt mit einem Gefühl belegen
• Eine blockierende Abfrage über pg_locks finden und die Kette bis zum Verursacher zurückverfolgen
• Mit pg_stat_statements die teuersten Abfragen einer Instanz benennen — nach Gesamtlast, nicht nach Einzellaufzeit

Formate und Ablauf

Gearbeitet wird an einer Übungsdatenbank mit vorbereiteten Problemfällen — jeder Abschnitt hat einen Messteil. Bei Inhouse-Seminaren nehmen wir gerne eure eigenen langsamen Abfragen als Beispiel; das ist meist der lehrreichere Weg. Für die Messwerkzeuge pg_stat_statements und auto_explain bringen wir eine vorbereitete Übungsumgebung mit — auf eurer eigenen Instanz setzen sie voraus, dass die Erweiterungen geladen sind, was einen Neustart bedeutet. Das klären wir vorab.

Verwandte Seminare und Vertiefung

Wenn ihr dieselben Fragen für mehrere Datenbanksysteme klären wollt, ist Datenbankübergreifendes Performance-Tuning der passendere Kurs: dort geht es um die Methode — Ausführungspläne, Indexstrategie, Anti-Patterns — herstellerneutral. Dieses Seminar setzt eine Ebene tiefer an. Die Themen berühren sich an einigen Stellen — Ausführungspläne, MVCC, Sperren, Indexauswahl: dort werden sie systemneutral als Methode eingeführt, hier an der PostgreSQL-Implementierung durchgerechnet. Wer beide bucht, hört sie trotzdem nicht zweimal: bei einer gemeinsamen Buchung stimmen wir Themenschnitt und Dauer vorab miteinander ab und legen die Überschneidungen zusammen. Für den Betrieb der Instanz — Installation, Benutzerverwaltung, Sicherung — ist PostgreSQL Administration der Nachbar, und wer Geschäftslogik in die Datenbank verlagert, findet in PL/pgSQL-Programmierung die Sprachseite.

Fachlich vorbereitet ist das Thema in unseren Artikeln: Indexe optimieren zeigt die Abfragen, mit denen sich ungenutzte und doppelte Indexe finden lassen, die Performance-Settings sind die Referenz zu den Konfigurationsparametern, VACUUM, REINDEX und CLUSTER behandelt die Wartungsseite und Das Betriebssystem unter PostgreSQL die Schicht darunter. Alle weiteren PostgreSQL-Seminare stehen in der Kategorie PostgreSQL.

Häufige Fragen (FAQ)

Wie lange dauert das Seminar?

Drei Tage. Der Stoff ist breit — Planer, Vacuum, Indexe, Konfiguration, Sperren, Partitionierung, Messwerkzeuge —, und jeder Abschnitt hat einen praktischen Teil. Wenn ihr nur einen Ausschnitt braucht, kürzen wir gezielt; sprich uns bei der Anfrage darauf an.

Worin unterscheidet es sich vom datenbankübergreifenden Tuning-Seminar?

Das übergreifende Seminar vermittelt die Methode, die für jedes relationale System gilt: Ausführungspläne lesen, Indexe entwerfen, Anti-Patterns erkennen. Dieses hier behandelt die PostgreSQL-Eigenheiten, die sich neutral gar nicht erklären lassen — MVCC und Bloat, Autovacuum, die Indextypen jenseits von B-Tree, das Zusammenspiel von shared_buffers mit dem Dateicache. Die gemeinsamen Themen — Ausführungspläne, MVCC, Sperren — werden dort neutral eingeführt und hier PostgreSQL-spezifisch vertieft. Wer aus dem übergreifenden Seminar kommt, erkennt sie wieder und geht eine Ebene tiefer. Und wer beides zusammen bucht, bekommt sie nicht doppelt: dann schneiden wir die Inhalte im Vorgespräch zusammen und passen die Dauer entsprechend an.

Brauche ich Administrationskenntnisse?

Nein. Du solltest PostgreSQL benutzt haben, aber weder Cluster aufgesetzt noch die Konfigurationsdatei je geöffnet haben müssen. Beides wird im Seminar erklärt, soweit es fürs Tuning gebraucht wird.

Welche PostgreSQL-Version wird verwendet?

Eine aktuelle Version. Wenn ihr produktiv auf einem älteren Stand arbeitet, richten wir die Beispiele danach aus — bei den Statistik- und Partitionierungsthemen sind die Versionsunterschiede erheblich.

Arbeiten wir an unseren eigenen Daten?

Bei einer Inhouse-Schulung gerne. Eigene langsame Abfragen sind das beste Übungsmaterial, weil die Ergebnisse sofort einen Wert haben. Im offenen Seminar arbeiten wir an einer Übungsdatenbank mit vorbereiteten Problemfällen. Werden bei einer Inhouse-Schulung personenbezogene Daten berührt, schließen wir vorab eine Vereinbarung zur Auftragsverarbeitung — das ist Routine und kostet keinen Seminartag.

Wie viele Teilnehmer sind möglich?

Wir arbeiten in kleinen Gruppen, damit individuelle Fragen Raum haben. Die genaue Teilnehmerzahl stimmen wir bei der Anfrage mit dir ab.

Was kostet die Teilnahme?

Der Preis richtet sich nach Format, Umfang und Teilnehmerzahl — gerne auf Anfrage. Preise verstehen sich netto zzgl. gesetzlicher Umsatzsteuer; das Angebot richtet sich an Unternehmen, Behörden und Selbstständige.

Seminar anfragen

Nach deiner Anfrage melden wir uns mit einem Terminvorschlag und klären, wo bei euch der Schuh drückt — Planer, Vacuum oder Konfiguration. Wenn ihr eigene Abfragen mitbringen möchtet, sehen wir sie uns im Rahmen der Anfrage kurz an, vertraulich und nur zu diesem Zweck. Bitte schickt sie ohne personenbezogene Echtdaten — Struktur und Ausführungsplan reichen uns.