Die meisten Performance-Probleme in PostgreSQL sitzen nicht in der Hardware. Sie sitzen in Abfragen, die den Server zwingen, viel zu viele Daten zu lesen, unnötig zu sortieren oder eine ungünstige Verbund-Strategie zu wählen. Solche Abfragen sind nicht kaputt — sie funktionieren. Sie kosten nur ein Vielfaches.
Der Aufwand steht im Plan, nicht im Ergebnis
Eine Berichtsabfrage liefert 25 Zeilen. Wie viele sie dafür gelesen hat, siehst
du der Ausgabe nicht an. Deshalb ist EXPLAIN (ANALYZE, BUFFERS) das eigentliche
Werkzeug: ANALYZE führt die Abfrage wirklich aus und zeigt gemessene Werte
statt Schätzungen, BUFFERS zählt die gelesenen Seiten.
Die aussagekräftigste Zeile heißt Rows Removed by Filter. Sie sagt dir, wie
viel der Server gelesen und danach wieder weggeworfen hat — der klassische
Hebel. Und ein häufiger Irrtum: cost ist keine Millisekundenangabe, sondern
ein einheitenloses Vergleichsmaß.
Wo man zuerst hinsieht — und wo nicht
Der auffälligste Knoten ist selten der teure. Eine Sortierung über 25 Zeilen steht prominent im Plan und kostet fast nichts, während darunter ein sequentieller Durchlauf über die größte Tabelle läuft. Wer oben optimiert, misst danach dieselbe Laufzeit.
Ähnlich verräterisch: Weichen geschätzte und tatsächliche Zeilenzahl stark
voneinander ab, ist meist die Tabellenstatistik das Thema — ein ANALYZE, kein
weiterer Index.
Mehr dazu im Seminar
Wie man von der Messung zur Maßnahme kommt, welcher Indextyp zu welchem Muster passt und warum ein Index auch Geld kostet, zeigt das Modul Abfrage-Performance und Indizes — mit Video und Kapitelübersicht. Zum Nachschlagen daneben gibt es das Cheat Sheet.