Datenbank PostgreSQL: Multithreading am Horizont?

Ein Post auf der Mailing-Liste schlägt eine Umstellung der Datenbank auf ein Multithreading-Modell vor. Unter den Antworten finden sich einige Bedenken.

In Pocket speichern vorlesen Druckansicht 22 Kommentare lesen
Lesezeit: 3 Min.
Inhaltsverzeichnis

Ein Beitrag auf der Mailing-Liste des PostgreSQL-Entwicklungsteams schlägt die Umstellung der Datenbank von einem Multiprozess- auf ein Multithreading-Modell vor. Heikki Linnakangas hat dazu laut eigenen Angaben mit Personen auf der PostgreSQL-Konferenz PGCon gesprochen, die Ende Mai bis Anfang Juni stattfand.

Derzeit hat PostgreSQL eine Multiprozess-Architektur. Linnakangas schlägt vor, stattdessen den gesamten Datenbankserver in einem Prozess mit mehreren Threads umzusetzen. Die denkbare Motivation dazu findet sich in einem Beitrag von Andres Freund: Das derzeitige Prozessmodell stößt wohl vor allem auf größeren Maschinen langsam an seine Grenzen, da für viele Operationen der Overhead größer ist als beim Multithreading.

Linnakangas räumt ein, dass die Umstellung mit viel Aufwand verbunden ist und nicht innerhalb eines Release erfolgen kann. Neue Hauptversionen von PostgreSQL erscheinen im Jahresrhythmus: Im Oktober 2022 kam Version 15 heraus, und für PostgreSQL 16 hat im Mai die Betaphase begonnen.

Während des Übergangs sollen User für ein oder mehrere Releases zwischen der Multiprozess- und der Multithreading-Architektur wählen können. Zudem soll die Umstellung in Schritten erfolgen. Denkbar wäre, zunächst für jede Verbindung einen eigenen Thread zu verwenden und den Backend-Prozess durch einen Backend-Thread zu ersetzen.

Als Fernziel schlägt der Beitrag die Umsetzung mit einem Thread-Pool und einem Scheduler vor, der aktive Queries an Worker Threads verteilt. Denkbar wäre auch, eine Verbindung auf mehrere Threads zu verteilen oder Helper Threads für spezifische Aufgaben zu starten.

In dem Thread zu dem Mail-Beitrag finden sich sowohl Zustimmung als auch kritische Töne. Neben der Befürchtung, dass die Umstellung in einem Desaster enden würde, finden sich differenziertere Fragen. So stellt ein Beitrag in den Raum, ob die Umstellung auf Multithreading tatsächlich die gewünschte Verbesserung bringt oder ob es nicht sinnvoller sei, sich auf andere Probleme der vertikalen Skalierbarkeit zu kümmern.

Ein anderer Beitrag geht tiefer auf die mangelnde Skalierbarkeit ein. Robert Haas schreibt zur mangelnden Skalierbarkeit: "Nicht alle Datenbanken haben dieses Problem, und PostgreSQL wird ohne grundlegende architektonische Änderungen damit nicht fertig werden." Allerdings fragt er auch, ob Multithreading wirklich alle Probleme lösen kann. Wirklich erforderlich sei wahrscheinlich, dass ungenutzte Verbindungen weder einen eigenen Prozess noch einen eigenen Thread belegen.

Es gab schon Ansätze, PostgreSQL mit Multithreading umzusetzen. Konstantin Knizhnik verweist auf ein Repository auf GitHub, das allerdings seit sechs Jahren keine Codeänderung mehr erhalten hat, und berichtet von seinen Erfahrungen. Der Performance-Zuwachs hätte für seine Testläufe damals lediglich zehn Prozent betragen. An einigen Stellen hätten die Threads durchaus Vorgänge aus Entwicklersicht vereinfacht und geholfen, zahlreiche Probleme zu beheben.

(rme)