2014-01-16 7 views
12

Ich habe eine materialisierte Ansicht namens price_changes für einige Berichterstattung verwendet. Ich habe auch einen Cron-Job, der die materialisierte Ansicht mit refresh materialized view price_changes aktualisiert. Alles funktioniert super.Überprüfen Sie die letzte aktualisierte Zeit für materialisierte Ansicht

Ich möchte Benutzern, die den Bericht betrachten, eine Meldung "Daten sind frisch ab X" geben. Ich könnte es irgendwo speichern, wenn Cron läuft, aber speichert postgres diese Metadaten schon irgendwo?

+0

Weitere Informationen hierzu: https://dba.stackexchange.com/q/58214/104401 – Wildcard

Antwort

9

Ich glaube nicht, dass irgendetwas in dem System eingebaut ist, das dies ab 9.3.4 bietet. Wenn ich das Datum der letzten Aktualisierung angeben muss, füge ich der ausgewählten Abfrage in der materialisierten Ansicht eine Spalte mit dem Namen "last_refresh" hinzu, da sich Daten in der materialisierten Ansicht erst ändern, wenn sie aktualisiert werden.

Ich bevorzuge dies auch aus Sicherheitsgründen, weil Sie den SQL-Benutzer möglicherweise nicht Zugriff auf die Systemtabellen geben möchten, wenn die Informationen dort gespeichert werden.

Je nachdem, ob Sie die Zeit benötigen, können Sie entweder:

  1. CURRENT_DATE
  2. now()

Gerade Datum:

CREATE MATERIALIZED VIEW mv_address AS 
SELECT *, CURRENT_DATE AS last_refresh FROM address;

mit Datum und Uhrzeit:

CREATE MATERIALIZED VIEW mv_address AS 
SELECT *, now() AS last_refresh FROM address;

-Update 2017.02.17:

PostgreSQL Version 9.4+ enthält jetzt CONCURRENTLY Option. Wenn Sie REFRESH MATERIALIZED VIEW CONCURRENTLY Option verwenden, beachten Sie, was @Smudge in den Kommentaren angegeben. Dies wäre wirklich nur ein Problem für große und häufig aktualisierte Datensätze. Wenn Ihr Datensatz klein oder selten aktualisiert wird, sollten Sie in Ordnung sein.

+8

Heads-up: Dieser Ansatz wird 'REFRESH MATERIALIZED VIEW CONCURRENTLY' veranlassen, jede Zeile jedes Mal zu aktualisieren. Für kleinere Datensätze mit seltenen Aktualisierungen ist dies kein großes Problem, aber bei vielen Daten und/oder häufigen Aktualisierungen kann die Rate von 'DELETE' und 'INSERT' die Fähigkeit des Autovakuum-Daemons, die Tabelle 'VACUUM' zu verursachen, überfordern grundlegende Abfrageleistung bis zum Sturzflug. – Smudge

+6

Sprechen aus der realen Welt Erfahrung - das Problem Smudge bezieht sich auf sehr leicht Schneebälle, bis Ihre Datenbank 100% ihrer Zeit mit dem Berg der toten Tupel zu verbringen und kann nicht wiederherstellen, bis Sie die materialisierte Ansicht DROP und neu erstellen. Verwenden Sie diese Lösung mit äußerster Vorsicht. – Jschiff