"Meine Datenbank ist langsam" – solche Hilferufe erreichen den Datenbanksupport häufig. Dann drängen sich immer zwei Fragen auf: Was genau ist langsam? Und: Ist es wirklich die Datenbank? Häufig wird die Schuld an allem Übel zu schnell auf die Datenbank geschoben. Aber selbst die schnellste und bestoptimierte Datenbank kann keinen unvorteilhaft gewählten Algorithmus in der Anwendung wettmachen. Manchmal entpuppt sich auch das Netzwerk als Übeltäter, aber das ist heutzutage seltener der Fall. Als dritte Gruppe von Verdächtigen kommen schließlich graphische Tools von Drittanbietern wie PgAdmin, PhpPgAdmin oder Tora in Betracht.

Prinzipiell findet sich die Ursache für langsame Datenbanken aber wie gesagt am häufigsten auf der SQL-Ebene. Ungenügend durchdachtes Design und wachstumsbedingte Verwerfungen führen die Hitliste der Fehler an. Weitere Beispiele sind: Sich gegenseitig blockierende Statements, unvorteilhaft formulierte Statements, Probleme bei Massenimporten, Probleme mit der Indizierung, langsame Algorithmen in Funktionen und anderes mehr. Nun soll es in diesem Artikel zwar weniger um SQL-Optimierung gehen, aber es ist wichtig, darauf zu verweisen, dass hier normalerweise der Schwerpunkt allen Tunings liegen muss.

Speicher-Stellschrauben

Dieser Artikel wird sich hauptsächlich mit der Optimierung von Datenbankparametern auseinandersetzen. Schon die Vielzahl der Variablen in der Datei »postgresql.conf« kann dabei dazu führen, dass der Admin den Überblick verliert, an welchen Schrauben gedreht werden sollte. Tröstlich ist: Für viele Installationen ist nur ein kleiner Bruchteil der mehr als hundert Tuningparameter von Bedeutung.

In vielen Fällen wichtig ist aber beispielsweise die Variable »max_connections« , die die Anzahl zeitgleicher Verbindungen zum Datenbankserver begrenzt. Ergänzend legt die