VACUUM gibt Speicherplatz an das Betriebssystem zurück

VACUUMgibt normalerweise keinen Speicherplatz an das Betriebssystem zurück, außer in einigen besonderen Fällen.
Aus den Dokumenten:

Die Standardform von VACUUMentfernt Dead Row-Versionen in Tabellen und Indizes und markiert den verfügbaren Speicherplatz für die zukünftige Wiederverwendung. Der Speicherplatz wird jedoch nicht an das Betriebssystem zurückgegeben, außer in dem speziellen Fall, dass eine oder mehrere Seiten am Ende einer Tabelle vollständig frei werden und eine exklusive Tabellensperre leicht erhalten werden kann. Im Gegensatz dazu werden VACUUM FULLTabellen aktiv komprimiert, indem eine vollständige neue Version der Tabellendatei ohne Totraum geschrieben wird. Dies minimiert die Größe der Tabelle, kann jedoch viel Zeit in Anspruch nehmen. Außerdem wird zusätzlicher Speicherplatz für die neue Kopie der Tabelle benötigt, bis der Vorgang abgeschlossen ist.

Die Frage ist: Wie kann dieser Datenbankstatus one or more pages at the end of a table become entirely freeerreicht werden? Dies kann über erfolgen VACUUM FULL, aber ich habe nicht genügend Platz, um es zu implementieren. Gibt es noch andere Möglichkeiten?

Verwenden Sie, um Speicherplatz an das Betriebssystem zurückzugeben VACUUM FULL. Ich nehme an, du rennst weg, während du dabei bist VACUUM FULL ANALYZE. Ich zitiere das Handbuch :

FULL

Wählt "volles" Vakuum, das mehr Platz beansprucht , aber viel länger dauert und den Tisch exklusiv sperrt. Diese Methode erfordert außerdem zusätzlichen Speicherplatz, da eine neue Kopie der Tabelle geschrieben und die alte Kopie erst freigegeben wird, wenn der Vorgang abgeschlossen ist. Normalerweise sollte dies nur verwendet werden, wenn eine erhebliche Menge an Speicherplatz innerhalb der Tabelle zurückgefordert werden muss.

Meine kühne Betonung.

CLUSTER auch das als sicherheitseffekt.

VACUUMNormalerweise erreicht Plain Ihr Ziel nicht ( "eine oder mehrere Seiten am Ende einer Tabelle sind völlig frei" ). Es werden keine Zeilen neu angeordnet und nur leere Seiten vom physischen Ende der Datei entfernt, wenn sich die Gelegenheit ergibt - wie in Ihrem Zitat aus den Anweisungen im Handbuch angegeben.

Sie können leere Seiten am Ende der physischen Datei erhalten, wenn Sie INSERTeinen Stapel von Zeilen und DELETEsie, bevor andere Tupel angefügt werden. Oder es kann zufällig passieren, dass genügend Zeilen gelöscht werden.

Es gibt auch spezielle Einstellungen, die möglicherweise verhindern VACUUM FULL, dass Speicherplatz freigegeben wird. Sehen:

• Wie kann man eine Tabelle für sehr häufige Updates optimieren?

Bereiten Sie leere Seiten am Ende einer Tabelle zum Testen vor

Die Systemspalte ctidrepräsentiert die physische Position einer Zeile. Sie müssen diese Spalte verstehen:

• Wie zerlege ich ctid in Seiten- und Zeilennummern?

Wir können damit arbeiten und eine Tabelle vorbereiten, indem wir alle Zeilen von der letzten Seite löschen:

DELETE FROM tbl t
USING (
   SELECT (split_part(ctid::text, ',', 1) || ',0)')::tid     AS min_tid
        , (split_part(ctid::text, ',', 1) || ',65535)')::tid AS max_tid
   FROM   tbl
   ORDER  BY ctid DESC
   LIMIT  1
   ) d
WHERE t.ctid BETWEEN d.min_tid AND d.max_tid;

Jetzt ist die letzte Seite leer. Dies ignoriert gleichzeitige Schreibvorgänge. Entweder Sie sind der einzige, der in diese Tabelle schreibt, oder Sie müssen eine Schreibsperre aktivieren, um Interferenzen zu vermeiden.

Die Abfrage ist optimiert, um qualifizierende Zeilen schnell zu identifizieren. Die zweite Zahl von a tidist der Tupelindex, der als vorzeichenlos gespeichert ist int2, und 65535ist das Maximum für diesen Typ ( 2^16 - 1), das ist also die sichere Obergrenze.

SQL Fiddle (Wiederverwenden einer einfachen Tabelle aus einem anderen Fall.)

Tools zum Messen der Zeilen- / Tabellengröße:

• Messen Sie die Größe einer PostgreSQL-Tabellenzeile

Festplatte voll

Für diese Vorgänge benötigen Sie Wackelspielraum auf der Festplatte. Es gibt auch das Community-Tool pg_repackals Ersatz für VACUUM FULL/ CLUSTER. Es vermeidet exklusive Sperren, benötigt aber auch freien Speicherplatz zum Arbeiten. Das Handbuch:

Benötigt freien Speicherplatz, der doppelt so groß ist wie die Zieltabelle (n) und -indizes.

Als letzte Möglichkeit können Sie einen Dump- / Wiederherstellungszyklus ausführen. Dadurch wird auch das Aufblähen von Tabellen und Indizes beseitigt. Eng verwandte Frage:

• Ich muss VACUUM FULL ohne verfügbaren Speicherplatz ausführen

Die Antwort da drüben ist ziemlich radikal. Wenn Ihre Situation dies zulässt (keine Fremdschlüssel oder anderen Referenzen, die das Löschen von Zeilen verhindern) und kein gleichzeitiger Zugriff auf die Tabelle, können Sie einfach:

Kopieren Sie die Tabelle von einem Remotecomputer mit viel Speicherplatz auf die Festplatte ( -afür --data-only):

Sichern Sie die Tabellendaten von der Remote-Shell aus:

pg_dump -h <host_name> -p <port> -t mytbl -a mydb > db_mytbl.sql

In einer pg-Sitzung ist TRUNCATEdie Tabelle:

-- drop all indexes and constraints here for best performance
TRUNCATE mytbl;

Stellen Sie von der Remote-Shell aus dieselbe Tabelle wieder her:

psql -h <host_name> -p <port> mydb -f db_mytbl.sql
-- recreate all indexes and constraints here

Es ist jetzt frei von toten Reihen oder Blähungen.

Aber vielleicht können Sie das einfacher haben?

• Können Sie genügend Speicherplatz auf der Festplatte schaffen, indem Sie nicht verwandte Dateien löschen (verschieben)?

• Können Sie VACUUM FULLzuerst die Tabellen einzeln verkleinern, um so genügend Speicherplatz freizugeben?

• Können Sie ausführen REINDEX TABLEoder REINDEX INDEXSpeicherplatz von aufgeblähten Indizes freigeben?

Was auch immer Sie tun, seien Sie nicht unbesonnen . Wenn Sie Zweifel haben, sichern Sie alles zuerst an einem sicheren Ort.