kann mir jemand sagen, warum das Statistik File pg_stat/pgstat.stat nach dem Start des Servers entfernt wird?
Mir ist klar, dass Statistiken nur in Memory existieren und die Datei im Grunde nur benötigt wird, um die Statistiken nach einem Neustart des Clusters zu erhalten. Würde die Datei aber nicht gelöscht, wäre sie Bestandteil des pg_basebackup. Da das Stoppen des Cluster die Erstellung auslöst, könnte ja genauso gut auch pg_basebackup diese Erstellung anstossen.
Hmm, laut den Kommentaren im Source Code wird die Datei nur gelöscht, wenn Postgres vorher nicht sauber beendet wurde (“unless preceded by a crash, in which case all stats are discarded”)
Wenn es so wäre, fände ich das ok und verständlich.
Ich habe PostgreSQL Datenbanken in den Versionen 15 und 16 und bei allen wird die pgstat.stat Datei beim Stoppen des Cluster über den Systemd oder pg_ctl erstellt. Damit sollte der Cluster ja sauber gestoppt worden sein.
Wenn ich den Cluster dann wieder starte ist das Verzeichnis pg_stat im Anschluss leer.
In den Kommentaren zur pgstat.c steht auch:
/*
Remove the stats file. This is currently used only if WAL recovery is
needed after a crash.
Should only be called by the startup process or in single user mode.
*/
Der Standard Shutdown Mode ist “fast” und in der Log Datei gibt es nach dem Start keine Infos zu einem Recovery. Damit hätte ich erwartet, dass die Datei beim Starten nicht gelöscht wird.
Das File wird beim Shutdown geschrieben, beim Start eingelesen und gelöscht. Wenn ein Crash passiert ist, wird das File ignoriert und gelöscht.
Siehe die Kommentare in src/backend/utils/activity/pgstat.c:
* Statistics are loaded from the filesystem during startup (by the startup
* process), unless preceded by a crash, in which case all stats are
* discarded. They are written out by the checkpointer process just before
* shutting down, except when shutting down in immediate mode.
Ich kann nicht sicher sagen, warum bei einem Crash das File ignoriert wird. Ich vermute, daß man sicherheitshalber lieber den Standpunkt bezieht: “Ich bin nicht sicher, ob die Statistiken OK sind oder nicht, deshalb habe ich lieber keine”.
Ein Online Base Backup ist kein konsistenter Zustand der Datenbank und wird wie ein Crash behandelt. Der Unterschied ist nur, daß von einem anderen Checkpoint wiederhergestellt wird.
Ich nehme an, die Motivation hinter der Frage ist, daß Sie gerne nach dem Restore eines Base Backups Statistiken haben würden. Für diesen Zweck empfehle ich, nach dem Restore ein datenbankweites ANALYZE laufen zu lassen. Das stellt immerhin die Statistiken her, die Autovacuum zum guten Funktionieren braucht.
Ich habe verstanden das es definitiv aktuell so gewollt ist, dass die Datei nach dem Start nicht mehr vorhanden ist.
Mir ist nun auch klar, dass die Datei nach einem Crash oder auch einen Base Backup ignoriert werden soll. Ich aktualisiere die Statistiken manuell nach einem Restore des Base Backup, damit ist grundsätzlich alles ok.
Nebenbei, auch die Views wie z.B. pg_stat_wal oder pg_stat_bgwriter verlieren ihre Daten.
Was mir hingegen nicht klar ist, warum wird auf die Statistiken überhaupt verzichtet? Wenn ich eine mehrere Terabyte große Datenbank habe kostet die Aktualisierung der Statistiken schon einiges an Zeit und Ressourcen. Ich finde, selbst schlechte Statistiken sind besser als gar keine, zumal sich ja auch nur ein sehr kleiner Teil der Daten wirklich ändert.
Was den Vacuum Prozess betrifft, da würde ich davon ausgehen, dass er meint die Tabelle sei leer. Dann reichen ja die im Standard verwendeten 50 Zeilen Änderungen um den Vacuum auszulösen. Wenn er dann feststellt, da sind 25 Millionen Zeilen drin ist ja auch alles gut.
Aber fehlende Statistiken haben auch einen Einfluss auf Ausführungspläne und damit auf Query Performance.
Technisch habe ich alles verstanden, mir fehlt nur das warum
Nach allen Tests kann ich meine Frage nach dem Warum beantworten. Es spielt keine große Rolle ob die Statistiken vorhanden sind oder nicht.
Der Vacuum Prozess behandelt die Tabellen als leere Tabellen und startet mit einer Analyse im Standard nach 50 Zeilenänderungen. Wird die Tabelle nicht angefasst, braucht es auch keinen Vacuum Prozess.
Einziger Nachteil: tote Zeilen bleiben nach dem Neustart ohne Statistiken so lange bestehen, bis sich die 50 Zeilen geändert haben.
Der Optimizer scheint diese Informationen gar nicht zu verwenden. Ich habe es nicht geschafft auch nur einen Ausführungsplan zu verändern. Die Pläne sind identisch, egal ob ich Statistiken habe oder nicht.
Über zwei Jahrzehnte Oracle Datenbanken haben bei mir wohl Spuren hinterlassen.
Es gibt zwei Arten von Statistiken in der Datenbank:
Die „Tabellenstatistiken”, die die Verteilung der Daten in den Tabellen beschreiben und vom Optimizer verwendet werden. Die sind in den Tabellen pg_statistic und pg_class gespeichert und gehen bei einem Crash nicht verloren.
Die Statistiken, die beschreiben, was auf der Datenbank passiert ist: wievele Index Scans, wieviele Updates, wieviele Deadlocks, wieviele tote Zeilen und vieles mehr. Die werden im Memory gehalten, im “statistics file” persistiert und gehen nach einem Crash verloren.
Wie Sie richtig beobachtet haben, ist das kein Beinbruch. Allenfalls verliert Autovacuum sein Hirn, aber das macht normalerweise keine großen Probleme.
