是否有可能永遠不會在 PostgreSQL 中執行vacuum full
由於
VACUUM FULL鎖表，在我們的生產環境中對我們來說是不可接受的。是否可以只在生產系統上執行
VACUUM而從不執行？VACUUM FULL是否
VACUUM使新空間可重複使用INSERT？
為了了解它們之間的區別
- 真空
- 真空分析
- 真空滿，
需要對 PostgreSQL 的體系結構有基本的了解。
從幾個9s 1我們被告知：
- PostgreSQL 不使用 IN-PLACE 更新機制，所以按照 DELETE 和 UPDATE 命令的設計方式，
+ 每當執行 DELETE 操作時，它會將現有元組標記為 DEAD，而不是物理刪除這些元組。 + 同樣，每當執行 UPDATE 操作時，它會將相應的現有元組標記為 DEAD 並插入一個新元組（即 UPDATE 操作 = DELETE + INSERT）。
這會導致所謂的“膨脹”——即表會變得更大，即使由於這些死元組而導致記錄數保持不變。
從EnterpriseDB 2，我們有：
- 當真空程序執行時，這些死元組佔用的空間被標記為可被其他元組重用。
這與刪除文件系統中的文件類似——該空間僅被標記為可重用，實際上並沒有刪除任何內容。這無關緊要 - 需要注意的重要一點是，該行佔用的空間再次可用於該表的 PostgreSQL 伺服器！
和之間的主要區別在於，使用 a ，釋放的空間也可供作業系統使用！如果您希望執行備份並且磁碟空間不足，這可能會很有用。從這裡：
VACUUM``VACUUM FULL``VACUUM FULL
- Vacuum full 取出排他鎖並重建表，使其沒有空塊（我們現在假設填充因子為 100%）。
因此，
VACUUM FULL類似於對磁碟文件進行碎片整理（考慮磁碟文件 ≡ PostgreSQL 表），從Percona 3我們有：VACUUM FULL 是 PostgreSQL 安裝可用的預設選項，它允許我們重新建構表。
$$ Emphasis mine $$
但是，此重建確實需要Access Exclusive Lock，正如手冊指出的那樣：
- 訪問獨家
與所有模式的鎖衝突（ACCESS SHARE、ROW SHARE、ROW EXCLUSIVE、SHARE UPDATE EXCLUSIVE、SHARE、SHARE ROW EXCLUSIVE、EXCLUSIVE 和 ACCESS EXCLUSIVE）。這種模式保證 持有者是唯一以任何方式訪問表的事務。
$$ Emphasis mine $$
顯然，正如您所指出的，完全重寫該表並不適合生產。手冊甚至說：
- 通常這應該只在需要從表中回收大量空間時使用。
所以，回答你的2個問題：
問：1)
does the vacuum make the space reuseable for the new insert?是的，確實如此，但更重要的是，它不需要訪問獨占鎖。從文件中，我們發現：
Autovacuum 工作人員通常不會阻止其他命令。
Autovacuum 是
VACUUM沒有的FULL，通常在postgresql.conf文件中配置。
VACUUM需要一個 SHARE UPDATE EXCLUSIVE 鎖。同樣，來自手冊：
此模式保護表免受並發模式更改和 VACUUM 執行。
或者正如知識淵博的 PostgreSQL 貢獻者所解釋的那樣：
Autovacuum does take a lock on the table, but it is a weak lock which does not interfere with normal operations (SELECT, UPDATE,DELETE) 但會干擾添加索引或截斷表等操作。
上面引用的 EnterpriseDB 部落格給出了
"VACUUM and ANALYZE Best Practice Tips"- 就我個人而言，我通常會建議更新表的統計資訊以供優化器使用ANALYZE！VACUUM本文還可以幫助您決定何時可能要執行VACUUM.問 2)
主題中提出的問題。
Is it possible never to run vacuum full in PostgreSQL是的，可以永遠不執行它，尤其是在不擔心磁碟空間的情況下。然而，這可能是值得的，因為完整的表重寫（連同索引）可以對查詢性能產生有益的影響——物理順序的記錄可以減少需要掃描的頁面！
結論。
這是一個複雜的問題，一篇完整的文章不可能很長，但我強烈建議您閱讀此處的參考資料（以及此處、此處和此處的頁面（填充因子））。
當然，您不希望
VACUUM在繁忙時間中斷您的生產系統。決定最佳策略幾乎與 IT 中的所有其他事情相同 -"It depends!".需要考慮磁碟空間和 I/O 負載參數，您必須達成最適合所有利益相關者的折衷方案。
1）幾個9s 是一個優秀的站點，用於PostgreSQL 的所有內容。
2）EnterpriseDB也是一個優秀的站點，也是最大的PostgreSQL公司，擁有大量的核心團隊成員和貢獻者。
- Percona，雖然以前是一家 MySQL 公司，但現在也有一個 PostgreSQL 發行版，並且他們贊助了有前途的pg_stat_monitor擴展（另見此處）。他們受到高度評價。