Es ist viel Es ist effizienter, die Zeitzone für Ihre Importsitzung festzulegen, als die Werte später zu aktualisieren.
Ich habe den Eindruck, dass Sie sich die Zeitzone wie eine Einstellung vorstellen, die für ansonsten unveränderte Werte in den Tabellen gilt. Aber so ist es überhaupt nicht. Betrachten Sie es als einen Input / Output-Modifikator. Tatsächlicher timestamp Werte (mit oder ohne Zeitzone) sind immer intern als UTC-Zeitstempel gespeichert (Anzahl Sekunden seit '2000-01-01 00:00'). ). Viele weitere Details:
Das UPDATE in deinem zweiten Beispiel verdoppelt sich die Größe der Tabelle, da jede einzelne Zeile ungültig gemacht und eine neue Version hinzugefügt wird (so wird UPDATE funktioniert mit MVCC
in Postgres). Neben der teuren Operation VACUUM müssen später mehr Arbeit leisten, um die aufgeblähten Tabellen zu bereinigen. Sehr ineffizient.
Es ist absolut sicher auf SET die lokale Zeitzone für die Sitzung. Dies wirkt sich in keiner Weise auf gleichzeitige Vorgänge aus. Übrigens, SET SESSION ist dasselbe wie einfaches SET weil SESSION ist ohnehin die Vorgabe.
Wenn Sie absolut sein wollen Natürlich können Sie die Einstellung auf die aktuelle Transaktion beschränken mit SET LOCAL . Ich zitiere das Handbuch hier
Zusammengesetzt:
BEGIN;
SET LOCAL timezone = 'UTC';
COPY tabledata FROM 'c:\Users\Public\Downloads\test.csv' DELIMITERS ',' CSV;
COMMIT;
Überprüfen Sie:
SHOW timezone;
