PostgreSQL 8.3 - autovacuum 的問題
我在 StackOverflow 上發布了這個，有人建議這個查詢更適合這裡。
我試圖鼓勵在一些 PostgreSQL 8.3 數據庫中使用和監控 autovacuum。
我經常遇到的一個反對意見是人們不“信任” autovacuum，或者 8.3 中的 autovacuum 中存在錯誤，這意味著它被忽略而不是調度清理。大多數情況下，我們的桌子都很小，這種方法似乎很有效。但是，對於我們更大的（以及大量更新的表），這確實不起作用（死元組計數增加，超過 max_fsm_pages，並且表沒有被清理等等）。
我只是想知道是否有人對 8.3 中的 autovacuum 有錯誤或不工作有參考。我自己的經驗表明 autovac 工作正常，並且在必要時向 pg_autovacuum 表添加條目就可以了。
我想了解 autovacuum 的問題（如果存在）。
我執行一些非常繁忙的 8.3 db 伺服器。當我第一次開始研究它們時，它們每半週都會破壞自由空間地圖設置並偏離軌道。解決方案是提高 fsm 設置，並使 autovacuum 更具侵略性。
autovacuum_vacuum_cost_delay 下降到 0 或 1ms autovacuum_vacuum_cost_limit 提高到 5000 max_fsm_pages 提高到 2M 到 10M，具體取決於機器 max_fsm_relations 提高到 10k 到 100k，具體取決於機器 autovacuum_max_workers 提高到 5 或 10，具體取決於機器
這些機器都有相當強大的 IO 子系統（8 到 32 個 15K SAS 驅動器和各種硬體 RAID 卡或 SAN）。
簡而言之，如果有人認為 8.3 中的 autovac 有問題並且不會使用它，那麼他們可能並不真正了解它，並且基於迷信而不是科學以特定方式行事。