自動清理高寫入、高更新和主要讀取的表類型
對於以下表格，什麼是好的自動真空設置（建議）：
- 高寫入表插入負載
一天內插入 30-10,000 次。該表可以在沒有負載的情況下閒置數週，但每周至少可以進行 3 次突發插入。
- 高更新表
它使用分區表數據，一次插入是我的表大小的 3-8 倍。
- 高寫表
單行只更新一次，但一天內會出現唯一鍵更新，需要更新，可能是 30-10,000 個鍵更新。
- 高讀表
大多數表都是高讀取表，設置為我的數據倉庫的填充因子 80，包含來自高更新表計算的表
我的刪除每月分批進行。與密鑰相關的所有內容都會被刪除或作為備份移動。
目前，對於高更新表，我的填充因子設置為 10-20 。
使用 TDS db.t3.large 但我在低流量時切換到 db.t3.micro。
另外，設置填充因子真的很低會減慢選擇嗎？
這個問題太寬泛了，但這裡有一些關於配置 autovacuum 的提示：
- 對於接收批量插入的表，
VACUUM之後執行顯式或使用 PostgreSQL v13。- 對於有很多更新的表，如果沒有更新的列被索引
fillfactor，a為 70 到 90（取決於行大小）是一件好事。10 或 20 只是對空間的瘋狂浪費。- 對於只讀取的表，無需關心 autovacuum。
- 使用批量刪除，您無能為力。如果您可以使用分區，那麼這種痛苦可能會完全消失。
當然low
fillfactor會對查詢性能產生負面影響；這就是您為更有效的數據修改所付出的代價：
- 對於順序掃描，影響很明顯：您也必須讀取所有空白空間。
- 對於只讀取單行的索引掃描，不會對性能產生影響。
- 讀取多行的索引掃描位於中間的某個位置，因為如果低，它們將不得不讀取更多塊
fillfactor，因為這些行將分佈在更多塊中。- 不要忘記對記憶體效率的影響：如果您的塊主要由空氣組成，則用於記憶體的 RAM 也將主要包含死空間。
網際網路上有一篇文件討論了RDS 上 PostgreSQL 中的AUTOVACUUM，標題為：了解 Amazon RDS for PostgreSQL 環境中的 autovacuum
尤其 ….
Autovacuum 是一個自動執行 VACUUM 和 ANALYZE（收集統計資訊）命令的守護程序。Autovacuum 檢查數據庫中的膨脹表並回收空間以供重用。
本質上，我建議執行預設值，因為AUTOVACUUM將負責清理表並為您更新統計資訊。
但是，您必須監控您的 PostgreSQL RDS 實例是否在跟上內務管理方面做得很好。您可以使用我提到的文章中的腳本：
SELECT relname AS TableName ,n_live_tup AS LiveTuples ,n_dead_tup AS DeadTuples ,last_autovacuum AS Autovacuum ,last_autoanalyze AS Autoanalyze FROM pg_stat_user_tables;這將產生如下內容：
tablename | livetuples | deadtuples | autovacuum | autoanalyze --------------------------+------------+------------+-------------------------------+------------------------------- cfgdateval | 1666 | 0 | 2020-02-26 12:32:13.851917+00 | 2020-02-26 12:32:13.87854+00 atcontval | 2940 | 0 | 2018-06-07 09:53:30.664645+00 | 2019-11-28 15:10:15.256083+00 cfgintval | 206 | 0 | 2020-02-26 12:32:13.815353+00 | 2020-02-26 12:32:13.815787+00 cfgaggval | 26 | 0 | | 2017-07-26 18:56:23.161035+00 cfgobjval | 3366 | 0 | 2020-02-26 12:32:13.933712+00 | 2020-02-26 12:32:13.959892+00 atintval | 169080 | 0 | | 2018-06-07 09:53:33.821121+00 atobjval | 259728 | 0 | | 2018-06-07 09:53:32.557788+00 cfgstrval | 1616 | 0 | 2020-02-26 12:32:13.752583+00 | 2020-02-26 12:32:13.803132+00 ataggval | 182790 | 0 | | 2018-06-07 09:53:30.566021+00 coolinking | 59375 | 0 | 2017-05-05 08:47:09.865774+00 | 2017-05-05 09:36:07.292082+00 cooobject | 31791 | 13 | | 2017-05-05 09:01:06.672438+00如果您有包含大量死元組的表並且沒有執行AUTOVACUUM，那麼您可能需要考慮調整 Autovacuum 設置：
select category, name,setting,unit,source,min_val,max_val from pg_settings where category = 'autovacuum' ;輸出：
category | name | setting | unit | source | min_val | max_val | boot_val ------------+-------------------------------------+-----------+------+--------------------+---------+------------+----------- Autovacuum | autovacuum | on | | default | | | on Autovacuum | autovacuum_analyze_scale_factor | 0.05 | | configuration file | 0 | 100 | 0.1 Autovacuum | autovacuum_analyze_threshold | 50 | | default | 0 | 2147483647 | 50 Autovacuum | autovacuum_freeze_max_age | 200000000 | | default | 100000 | 2000000000 | 200000000 Autovacuum | autovacuum_max_workers | 3 | | default | 1 | 262143 | 3 Autovacuum | autovacuum_multixact_freeze_max_age | 400000000 | | default | 10000 | 2000000000 | 400000000 Autovacuum | autovacuum_naptime | 30 | s | configuration file | 1 | 2147483 | 60 Autovacuum | autovacuum_vacuum_cost_delay | 20 | ms | default | -1 | 100 | 20 Autovacuum | autovacuum_vacuum_cost_limit | -1 | | default | -1 | 10000 | -1 Autovacuum | autovacuum_vacuum_scale_factor | 0.1 | | configuration file | 0 | 100 | 0.2 Autovacuum | autovacuum_vacuum_threshold | 50 | | default | 0 | 2147483647 | 50有關何時以及是否應該修改AUTOVACUUM設置的更多詳細資訊，請參閱在 Amazon RDS for PostgreSQL 中調整 Autovacuum 的案例研究。
一般來說，PostgreSQL 在處理內務方面做得很好。