Synopsis
VACUUM [ FULL | FREEZE ] [ VERBOSE ] [ table ] VACUUM [ FULL | FREEZE ] [ VERBOSE ] ANALYZE [ table [ (column [, ...] ) ] ]
描述
VACUUM 回收已刪除元組佔據的存儲空間。在一般的 PostgreSQL 操作裏，那些已經 DELETE 的元組或者被 UPDATE 過後過時的元組是沒有從它們所屬的表中物理刪除的；在完成 VACUUM 之前它們仍然存在。因此我們有必須週期地運行 VACUUM，特別是在常更新的表上。
如果沒有參數，VACUUM 處理當前數據庫裏每個表，如果有參數，VACUUM 只處理那個表。
VACUUM ANALYZE 先執行一個 VACUUM然後是給每個選定的表執行一個ANALYZE。對於日常維護腳本而言，這是一個很方便的組合。參閱ANALYZE獲取更多有關其處理的細節。
簡單的 VACUUM （沒有FULL）只是簡單地回收空間並且令其可以再次使用。這種形式的命令可以和對錶的普通讀寫並行操作，因爲沒有請求排他鎖。VACUUM FULL執行更廣泛的處理，包括跨塊移動元組，以便把表壓縮到最少的磁盤塊數目裏。這種形式要慢許多並且在處理的時候需要在表上施加一個排它鎖。
FREEZE 是一種特殊用途的選項，它導致元組儘可能快地標記爲"凍結(frozen)"，而不是等到它們已經相當老的時候才標記。如果在同一個數據庫上沒有其它運行着的事務的時候完成這個命令，那麼系統就保證在數據庫裏的所有元組都是"凍結(frozen)"的，因此不會有事務 ID 重疊的問題，而和數據庫未清理的時間沒有關係。我們不建議把FREEZE 用做日常用途。我們用它的唯一目的是準備和用戶定義的模板數據庫聯接的時候，或者是其它完全是隻讀的，不會等到日常維護性VACUUM 操作的數據庫。參閱 Chapter 22 獲取細節。
參數
- FULL
-
選擇"完全"清理，這樣可以恢復更多的空間，但是花的時間更多並且在表上施加了排它鎖。
- FREEZE
-
選擇激進的元組"凍結"。
- VERBOSE
-
爲每個表打印一份詳細的清理工作報告。
- ANALYZE
-
更新用於優化器的統計信息，以決定執行查詢的最有效方法。
- table
-
要清理的表的名稱（可以有模式修飾）。缺省時是當前數據庫中的所有表。
- column
-
要分析的具體的列/字段名稱。缺省是所有列/字段。
注意
我們建議在經常VACUUMM（清理）（至少每晚一次）生產數據庫，以保證不斷地刪除失效的行。尤其是在增刪了大量記錄之後，對受影響的表執行VACUUM ANALYZE命令是一個很好的習慣。這樣做將更新系統目錄爲最近的更改，並且允許PostgreSQL查詢優化器在規劃用戶查詢時有更好的選擇。
我們不建議日常使用 FULL 選項，但是可以在特殊情況下使用。一個例子就是在你刪除了一個表的大部分行之後，希望從物理上縮小該表以減少磁盤空間佔用。VACUUM FULL通常要比單純的VACUUM 收縮更多表的尺寸。
例子
下面是一個在 regression （蛻變）數據庫裏某個表上執行 VACUUM的一個例子：
regression=# VACUUM VERBOSE ANALYZE onek; INFO: vacuuming "public.onek" INFO: index "onek_unique1" now contains 1000 tuples in 14 pages DETAIL: 3000 index tuples were removed. 0 index pages have been deleted, 0 are currently reusable. CPU 0.01s/0.08u sec elapsed 0.18 sec. INFO: index "onek_unique2" now contains 1000 tuples in 16 pages DETAIL: 3000 index tuples were removed. 0 index pages have been deleted, 0 are currently reusable. CPU 0.00s/0.07u sec elapsed 0.23 sec. INFO: index "onek_hundred" now contains 1000 tuples in 13 pages DETAIL: 3000 index tuples were removed. 0 index pages have been deleted, 0 are currently reusable. CPU 0.01s/0.08u sec elapsed 0.17 sec. INFO: index "onek_stringu1" now contains 1000 tuples in 48 pages DETAIL: 3000 index tuples were removed. 0 index pages have been deleted, 0 are currently reusable. CPU 0.01s/0.09u sec elapsed 0.59 sec. INFO: "onek": removed 3000 tuples in 108 pages DETAIL: CPU 0.01s/0.06u sec elapsed 0.07 sec. INFO: "onek": found 3000 removable, 1000 nonremovable tuples in 143 pages DETAIL: 0 dead tuples cannot be removed yet. There were 0 unused item pointers. 0 pages are entirely empty. CPU 0.07s/0.39u sec elapsed 1.56 sec. INFO: analyzing "public.onek" INFO: "onek": 36 pages, 1000 rows sampled, 1000 estimated total rows VACUUM
