News zu PostgreSQL Datenbank
Mit pg_plan_advice Ausführungspläne gezielt beeinflussen und Vorgaben mit pg_stash_advice speichern: Wir haben untersucht, was das für die Abfrageperformance bedeutet – und wo die Grenzen liegen.
Index Scan oder Seq Scan? Hash Join oder Nested Loop? Normalerweise entscheidet der PostgreSQL-Planner, welcher Ausführungsplan voraussichtlich am günstigsten ist. Doch was tun, wenn eine Abfrage auffällig langsam läuft und ein anderer Plan bessere Ergebnisse verspricht?
Genau hier kommen pg_plan_advice und pg_stash_advice ins Spiel: Mit pg_plan_advice lassen sich bestimmte Planner-Entscheidungen gezielt beeinflussen – etwa die Zugriffsmethode, Join-Reihenfolge oder das Join-Verfahren. Das Modul schränkt dabei die Auswahl des Planners ein. pg_stash_advice ergänzt die Möglichkeit, solche Vorgaben einer Query-ID zuzuordnen und bei der Planung passender Abfragen automatisch anzuwenden.
Wir haben beide Werkzeuge mit PostgreSQL 19beta3 im Labor getestet. Die wichtigste Erkenntnis: Mehr Kontrolle über den Ausführungsplan bedeutet nicht automatisch mehr Performance.
Getestet wurde auf einer einzelnen VMware-Instanz mit 16 virtuellen CPUs und 64 GB RAM. PostgreSQL war mit 128 MiB shared_buffers und bis zu zwei parallelen Workern pro Abfrage konfiguriert.
Die künstliche Datenbasis bestand aus 500.000 Verkaufsdatensätzen sowie Kunden‑, Produkt- und Datumstabellen. Wir verglichen die freie Plannerwahl mit gezielten Vorgaben für Zugriffsmethoden und Joins. Hinzu kamen Tests mit geänderter Datenverteilung und gespeicherten Vorgaben.
Die vollständigen Vergleichsserien enthielten jeweils zwei Aufwärmläufe und zehn Messungen pro Variante. Insgesamt entstanden 471 verwertbare Messungen. Zusätzlich prüften wir, ob die Abfragen weiterhin dieselben Ergebnisse lieferten.
Index Scan oder Seq Scan: Die Treffermenge zählt
Bei einer Abfrage mit hoher Selektiviät benötigte ein erzwungener vollständiger Tabellenscan rund 33 statt 0,14 Millisekunden. Mehrere vorgegebene Join-Verfahren machten die untersuchten Abfragen ebenfalls langsamer.
Die praktische Konsequenz: Dass eine Vorgabe angewendet wird, sagt noch nichts über ihren Nutzen aus. Entscheidend ist der gemessene Vergleich mit der freien Plannerwahl.
Ein passender Index brachte einen deutlichen Vorteil
Beim Produktfilter sank die Laufzeit mit einem passenden Index von etwa 48 auf 1,26 Millisekunden, jeweils als Median gemessen.
Die Werte stammen aus getrennten Messserien. Zusätzlicher Speicherbedarf und Schreibaufwand durch den Index wurden nicht untersucht. Trotzdem unterstreicht das Ergebnis: Zur PostgreSQL-Query-Optimierung gehört zunächst die Prüfung von Statistiken, Abfragestruktur und vorhandenen Indizes.
Gleiche Query-ID bedeutet nicht gleicher optimaler Plan
Abfragen mit unterschiedlichen Suchwerten können dieselbe Query-ID besitzen, obwohl verschiedene Ausführungspläne sinnvoll wären. Ein Filter auf ein seltenes Produkt kann beispielsweise von einem anderen Zugriff profitieren als ein Filter auf einen häufig vorkommenden Wert.
Eine gespeicherte Planvorgabe sollte deshalb mit repräsentativen Suchwerten geprüft werden. Nach Änderungen der Datenverteilung ist erneut zu bewerten, ob sie weiterhin einen Vorteil bringt.
Gelöschte Vorgaben können über zwischengespeicherte Pläne nachwirken
Im Labor zeigte sich: Nach dem Entfernen einer gespeicherten Vorgabe kann ein bereits zwischengespeicherter Ausführungsplan weiterverwendet werden.
Zum Rücknahmeweg gehört daher die Kontrolle, welcher Plan anschließend tatsächlich ausgeführt wird. Ein gelöschter Advice-Eintrag allein belegt noch nicht, dass wieder ein unbeeinflusster Plan zum Einsatz kommt.
Bevor du eine Planvorgabe dauerhaft einsetzt, empfiehlt sich dieses Vorgehen:
Ein möglicher Folgeversuch wäre ein kontrollierter, KI-gestützter Optimierungskreislauf. Dabei würde KI auffällig langsame Abfragen anhand ihrer Laufzeitdaten erkennen, Ausgangspläne analysieren und wenige begründete Alternativen mit pg_plan_advice testen.
Nur eine wiederholt bessere Vorgabe würde nach Prüfung verschiedener Suchwerte und der Ergebnisgleichheit über pg_stash_advice für einen begrenzten Testbetrieb hinterlegt. Anschließend müsste sie regelmäßig mit der freien Plannerwahl verglichen und bei Verschlechterungen zurückgenommen werden.
Dieser Kreislauf war nicht Bestandteil des beschriebenen Labortests. Ziel eines Folgeversuchs wäre eine überprüfbare Optimierung, die auch erkennt, wann ihre eigene Empfehlung nicht mehr sinnvoll ist.
pg_plan_advice und pg_stash_advice bieten zusätzliche Möglichkeiten, PostgreSQL-Ausführungspläne zu beeinflussen und nachgewiesene Planungsprobleme zu bearbeiten. Gute Statistiken, passende Indizes und belastbare Vergleichsmessungen bleiben dabei entscheidend.
Unsere Ergebnisse beziehen sich auf den beschriebenen PostgreSQL-19beta3-Laboraufbau. Sie lassen sich nicht pauschal auf andere Versionen oder produktive Umgebungen übertragen.
Du möchtest langsame PostgreSQL-Abfragen analysieren oder das Optimierungspotenzial deiner Ausführungspläne bewerten lassen? Unsere PostgreSQL-DBAs unterstützen dich dabei, Ursachen einzugrenzen und geeignete Maßnahmen für deine Umgebung zu prüfen.
Hier findest du weitere Infos aus der Welt von PostgreSQL aus unserem News & Insights Bereich.
Share this article
Sie sehen gerade einen Platzhalterinhalt von YouTube. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Mehr InformationenSie müssen den Inhalt von reCAPTCHA laden, um das Formular abzuschicken. Bitte beachten Sie, dass dabei Daten mit Drittanbietern ausgetauscht werden.
Mehr InformationenSie sehen gerade einen Platzhalterinhalt von Facebook. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Mehr Informationen