Neue Funktionen im Query Planner von Postgres 16

Neue Funktionen im Query Planner von PostgreSQL 16

• PostgreSQL 16 führt viele Verbesserungen am Query Planner ein, wodurch viele SQL-Abfragen schneller ausgeführt werden als in früheren Versionen.
• In den Release Notes von PG16 sind diese Planner-Verbesserungen zu sehen, aber da jede PostgreSQL-Version viele Änderungen enthält, ist es schwierig, zu jeder einzelnen Änderung eine ausführliche Erklärung zu geben.
• Dieser Blogpost bietet eine eingehende Analyse von 10 Verbesserungen im Query Planner von PostgreSQL 16 und zeigt anhand von Beispielen, was sich geändert hat, einschließlich eines Vergleichs der Planner-Ausgaben von PG15 und PG16.

10 Verbesserungen im Query Planner von PostgreSQL 16

• Inkrementelles Sortieren: Das inkrementelle Sortieren, das erstmals in PostgreSQL 13 eingeführt wurde, nutzt aus, wenn einige Ergebnismengen bereits nach einer oder mehreren führenden Spalten sortiert sind, und sortiert dann nur noch die verbleibenden Spalten.
• Aggregationen mit sortierten Daten: Der Query Planner von PostgreSQL 16 versucht nun, Pläne zu bilden, die Zeilen in sortierter Reihenfolge an Aggregationsknoten liefern.
• Memoization: Der Memoization-Plan-Knoten, der erstmals in PostgreSQL 14 eingeführt wurde, fungiert als Cache-Schicht, um doppelte Wertabfragen zu vermeiden.
• Anti-Join: PostgreSQL 16 ermöglicht es, bei der Ausführung von Anti-Joins die kleinere Tabelle zu hashen.
• Paralleler Hash-Join: PostgreSQL 16 unterstützt parallele Hash-Joins für die Join-Typen FULL und RIGHT.
• Optimierung von Window Functions: PostgreSQL 16 ermöglicht schnellere Window Functions im ROWS-Modus als im RANGE-Modus.
• Optimierung für stets ansteigende Window Functions: PostgreSQL 16 erweitert die Optimierung für Window Functions wie ntile(), cume_dist() und percent_rank().
• Join-Eliminierung bei partitionierten Tabellen: PostgreSQL 16 erlaubt die Optimierung zur Entfernung von LEFT JOIN bei partitionierten Tabellen.
• Verwendung von Limit für DISTINCT-Abfragen: Der Query Planner von PostgreSQL 16 fügt keinen Plan-Knoten zur Deduplizierung des Ergebnisses ein, wenn erkannt werden kann, dass alle Zeilen denselben Wert enthalten.
• Gelockerte Regeln für Merge Join: Der Query Planner von PostgreSQL 16 prüft beim Berücksichtigen von Merge Join nicht mehr, ob die Reihenfolge der Zeilen exakt übereinstimmt, sondern ob zumindest eine führende Spalte korrekt sortiert ist.

Meinung von GN⁺

• Die Verbesserungen am Query Planner in PostgreSQL 16 spielen eine wichtige Rolle für die Steigerung der Datenbankleistung. Besonders Funktionen wie inkrementelles Sortieren und Memoization ermöglichen eine effizientere Ausführung komplexer Abfragen.
• Diese Verbesserungen werden für Entwickler und Datenbankadministratoren, die PostgreSQL einsetzen, sehr nützlich sein. Vor allem in Systemen, die große Datenmengen verarbeiten, dürften Leistungsverbesserungen deutlich spürbar sein.
• Die kontinuierlichen Innovations- und Verbesserungsbemühungen der PostgreSQL-Community treiben die Weiterentwicklung von Open-Source-Datenbanktechnologie voran und bieten Anwendern und Unternehmen bessere Lösungen für das Datenmanagement.

[GN⁺]

Hacker-News-Kommentare

• Es gibt die Meinung, dass es gut wäre, wenn der Postgres-Abfrageplaner eine Abfrage während der Ausführung neu planen könnte. Wegen fehlender Informationen über die Datenverteilung können ineffiziente Ausführungspläne erstellt werden, was die Laufzeit stark beeinflussen kann. Wenn eine Abfrage langsamer als erwartet voranschreitet, wäre eine Funktion nötig, die sie auf Basis der aktuellen Fortschrittsinformationen neu plant. Da Postgres jedoch Streaming-Abfragen unterstützt, würde eine Planänderung während der Ausführung erhebliche Änderungen an der Infrastruktur erfordern.
• Ein Nutzer gibt an, für die Visualisierung von Abfragen explain.dalibo.com und www.pgexplain.dev zu verwenden. Beide Tools liefern ähnliche Ausgaben.
• Es wird angemerkt, dass Verbesserungen am Abfrageplaner ein wichtiger Teil einer Datenbank sind, aber meist nur dann auffallen, wenn sie nicht wie gewünscht funktionieren. Es wird die Erfahrung geteilt, dass der JIT(Just-In-Time)-Compiler in aktuellen Postgres-Versionen Heuristiken zur Nutzungszeit zu haben scheint, die nicht besonders robust wirken, und bei kleinen Datenmengen sogar verlangsamen kann, weshalb es sinnvoll sein kann, JIT zu deaktivieren.
• Es wird gefragt, wie oft die Änderungen bei realen Abfragen tatsächlich wirksam sind, insbesondere ob die Änderung „wenn möglich Limit statt DISTINCT verwenden“ in der Praxis überhaupt zum Tragen kommt. Außerdem wird gefragt, ob die Postgres-Entwickler dazu Informationen haben.
• Es gibt die Meinung, dass ein „Strict Mode“ für Anwendungstests nützlich wäre. In diesem Modus würde ein Fehler zurückgegeben, wenn kein Index vorhanden ist, der die Abfrage verbessern könnte, und über den Befehl CREATE INDICES FOR <sql> könnten die benötigten Indizes erzeugt werden. Zusätzlich wird ein Modus zur automatischen Indexerstellung für Entwicklung und interaktive Nutzung vorgeschlagen.
• Ein Freund eines Nutzers arbeitet als Microsoft-DBA für kleine und mittlere Unternehmen und behauptet, mit Postgres könne man keine ernsthafte Arbeit machen. Er sei überrascht gewesen, dass Postgres keinen Abfrageplaner habe, was jedoch eine falsche Information ist. Es wird gefragt, wie glaubwürdig die Behauptung ist, dass MSSQL größere Workloads als Postgres bewältigen könne.
• Es wird die Frage aufgeworfen, warum Postgres keine Hints implementiert.
• Es wird gefragt, warum die von Citus Data angekündigte Funktion nicht auf postgresql.org, sondern an anderer Stelle veröffentlicht wurde und ob es sich um eine kostenpflichtige Funktion oder eine Open-Source-Erweiterung handelt.
• Es wird gefragt, ab wann Postgres Indizes nutzen kann, um IS NOT DISTINCT FROM-Abfragen zu beschleunigen.
• Ein Kommentar wurde gemeldet und als flagged markiert.