Wenn Sie UPDATE- und DELETE-Anweisungen in einer Heap-Tabelle (Standardspeicher) ausführen und VACUUM regelmäßig ausführen, werden Sie vom Entwurf etwas aufgebläht. Der Heap-Speicher, der dem Standard-PostgreSQL-Speichermechanismus ähnelt, bietet Lesekonsistenz mithilfe von MVCC (Multi-Version Concurrency Control).
Wenn Sie einen Datensatz AKTUALISIEREN oder LÖSCHEN, befindet sich der alte Wert immer noch in der Tabelle und kann von noch im Flug befindlichen Transaktionen gelesen und gestartet werden, bevor Sie den Befehl UPDATE oder DELETE ausgegeben haben. Dies liefert die Lesekonsistenz für die Tabelle.
Wenn Sie eine VACUUM-Anweisung ausführen, markiert die Datenbank die veralteten Zeilen als verfügbar zum Überschreiben. Die Dateien werden nicht verkleinert. Es markiert nur Zeilen, damit sie überschrieben werden können. Wenn Sie das nächste Mal ein INSERT oder UPDATE ausführen, können die veralteten Zeilen nun für die neuen Daten verwendet werden.
Wenn Sie also 10% einer Tabelle zwischen dem Ausführen von VACUUM AKTUALISIEREN oder LÖSCHEN, werden Sie wahrscheinlich etwa 10% aufgebläht haben.
Greenplum hat auch Append-Optimized (AO) -Speicher, der MVCC nicht verwendet und stattdessen eine Sichtbarkeitskarte verwendet. Die Dateien sind auch etwas kleiner, so dass Sie eine bessere Leistung erhalten sollten. Die veralteten Zeilen werden mit der Sichtbarkeitskarte ausgeblendet, und VACUUM macht nichts, bis Sie den Prozentsatz gp_appendonly_compaction_threshold erreichen. Der Standardwert ist 10%. Wenn Sie in einer AO-Tabelle 10% aufgebläht haben und VACUUM ausführen, wird die Tabelle automatisch für Sie neu erstellt.
Append-Optimized heißt aus Gründen der Abwärtskompatibilität "appendonly", erlaubt aber UPDATE und DELETE. Hier ist ein Beispiel für eine AO-Tabelle:
CREATE TABLE sales
(txn_id int, qty int, date date)
WITH (appendonly=true)
DISTRIBUTED BY (txn_id);