Werden unter 9.1 noch regelmäßige VAKUUMANALYSEN empfohlen?

Ich benutze PostgreSQL 9.1 unter Ubuntu. Werden noch geplante VACUUM ANALYZEMaßnahmen empfohlen oder ist das automatische Absaugen ausreichend, um alle Anforderungen zu erfüllen?

Wenn die Antwort "es kommt darauf an" ist, dann:

• Ich habe eine große Datenbank (30 GiB komprimierte Speichergröße, 200 GiB Datenverzeichnis)
• Ich führe ETL in die Datenbank durch und importiere fast 3 Millionen Zeilen pro Woche
• Die Tabellen mit den häufigsten Änderungen werden alle von einer Mastertabelle geerbt, ohne Daten in der Mastertabelle (Daten werden nach Woche partitioniert).
• Ich erstelle stündliche Rollups und von dort aus tägliche, wöchentliche und monatliche Berichte

Ich frage, weil der Zeitplan VACUUM ANALYZEmeine Berichterstattung beeinflusst. Es hat eine Laufzeit von mehr als 5 Stunden und ich musste es diese Woche zweimal beenden, da es die regelmäßigen Datenbankimporte beeinträchtigte. check_postgresmeldet keine nennenswerte Aufblähung in der Datenbank, das ist also kein wirkliches Problem.

In den Dokumenten sollte sich Autovacuum auch um das Umbrechen der Transaktions-ID kümmern. Die Frage steht: brauche ich noch eine VACUUM ANALYZE?

VACUUM wird nur für aktualisierte oder gelöschte Zeilen in nicht temporären Tabellen benötigt. Natürlich machen Sie viele INSERTs, aber aus der Beschreibung geht nicht hervor, dass Sie auch viele UPDATEs oder DELETEs machen.

Diese Vorgänge können mit der pg_stat_all_tablesAnsicht verfolgt werden, insbesondere mit den Spalten n_tup_updund n_tup_del. Darüber hinaus gibt es eine n_dead_tupSpalte, die pro Tabelle angibt, wie viele Zeilen gesaugt werden müssen. ( Informationen zu Funktionen und Ansichten für die Erfassung von Statistiken finden Sie unter Überwachen von Statistiken im Dokument.)

Eine mögliche Strategie in Ihrem Fall wäre, den geplanten VACUUM zu unterdrücken, diese Ansicht im Auge zu behalten und zu überprüfen, an welchen Tabellen der Anstieg n_dead_tupsignifikant ist. Wenden Sie dann das aggressive VACUUM nur auf diese Tabellen an. Dies ist ein Gewinn, wenn es große Tabellen gibt, deren Zeilen nie gelöscht oder aktualisiert werden und das aggressive VACUUM nur bei kleineren Tabellen wirklich erforderlich ist.

Führen Sie jedoch weiterhin ANALYZE aus, damit der Optimierer immer über aktuelle Statistiken verfügt.

Ich sehe in Ihrer Frage nichts, autovacuumworum es nicht gehen würde. Dies hängt weitgehend vom Muster Ihrer Schreibaktivitäten ab . Sie erwähnen 3 Millionen neue Zeilen pro Woche, aber INSERT(oder COPY) erstellen in der Regel keinen Tabellen- und Indexüberhang. ( autovacuumMuss sich nur um Spaltenstatistiken , die Sichtbarkeitskarte und einige kleinere Jobs kümmern ). UPDATEund DELETEsind die Hauptursache für das Aufblähen von Tabellen und Indizes, insbesondere beim Targeting von Zufallszeilen. Ich sehe nichts davon in Ihrer Frage.

autovacuumhat einen langen Weg hinter sich und leistet in Postgres 9.1 oder höher hervorragende Arbeit. Ich würde mir die autovacuumEinstellungen ansehen . Wenn das Staubsaugen dazu neigt, Ihre Arbeitsbelastung zu beeinträchtigen, lesen Sie auch "Kostenbasierte Vakuumverzögerung" . Manuelles Staubsaugen sollte die seltene Ausnahme sein.

Wenn Sie viele zufällige UPDATEs haben, möchten Sie möglicherweise einen FILLFACTORniedrigeren Wert als 100 festlegen , um HOT-Updates sofort zuzulassen und die Notwendigkeit für zu verringern VACUUM. Mehr zu HOT Updates:

• Redundante Daten in Update-Anweisungen

Beachten Sie auch, dass temporäre Tabellen manuelles VACUUM& benötigen ANALYZE. Ich zitiere das Handbuch aufCREATE TABLE :

Der Autovacuum-Daemon kann nicht auf temporäre Tabellen zugreifen und diese daher nicht vakuumieren oder analysieren. Aus diesem Grund sollten geeignete Vakuum- und Analysevorgänge über SQL-Sitzungsbefehle ausgeführt werden. Wenn beispielsweise eine temporäre Tabelle in komplexen Abfragen verwendet werden soll, ist es ratsam, sie ANALYZEnach dem Auffüllen für die temporäre Tabelle auszuführen .

Ich bin damit einverstanden, dass es am besten ist, die automatischen Funktionen zu verwenden, anstatt sie datenbankweit auszuführen. In den meisten Fällen ist jedoch eine Optimierung pro Tabelle erforderlich.

Ich bin nicht ganz einverstanden mit der Wahl des Designs für Postgres, um Vakuum und Analyse zusammenzufügen. Ich habe mehrere Fälle gesehen, in denen Datenbanken, die viel einfügen / aktualisieren, aber wenig löschen, niemals analysiert werden und eine schlechte Leistung zeigen.

Die Lösung besteht darin, die Tabellen zu durchsuchen, die häufig verwendet werden und großen Abfragen unterliegen, und die Einstellungen für die automatische Analyse für diese Tabellen so festzulegen, dass sie ein oder alle zwei Tage analysiert werden.

Sie gelangen in der GUI auf der Registerkarte Auto Vakuum zu den Pro-Tisch-Einstellungen und sehen dort Analyseeinstellungen, die Sie unabhängig vom Vakuum einstellen können.

Die Einstellungen landen in der Reloptions-Tabelle und können mit der Abfrage angezeigt werden

SELECT c.relname, c.reloptions FROM pg_class c where reloptions is not null

und dort könnte ein Stichprobenwert einer aggressiven Analyse sein

{autovacuum_enabled=true,autovacuum_analyze_threshold=10,autovacuum_analyze_scale_factor=.01}

Um zu sehen, wann Ihre Tabellen das letzte Mal automatisch analysiert wurden, fragen Sie ab

select 
    relname, 
    n_dead_tup, 
    n_tup_ins, 
    n_tup_upd, 
    n_tup_del, 
    last_autoanalyze, 
    autoanalyze_count 
from pg_stat_user_tables 
where last_autoanalyze is not null 
order by last_autoanalyze desc;