一、數據庫應用類型
針對不同的應用模型，需要對數據庫配置進行優化：
1、網絡應用程序（WEB）
- 通常受 CPU 限制
- DB比RAM小得多
- 90% 或更多的簡單查詢
2、在線事務處理 (OLTP)
- 通常受 CPU 或 I/O 限制
- 數據庫數據量遠大於系統內存
- 20-40% 小數據寫入查詢
- 長事務和復雜的讀取查詢
3、數據倉庫 (DW)
- 通常受 I/O 或 RAM 限制
- 大量數據加載
- 大型復雜報表查詢
- 也稱為“決策支持”或“商業智能”
4、混合型應用(MIX)
- 混合 DW 和 OLTP 特性
- 各種的查詢組合
上述各種應用系統的需求存在差異，因此，建議在安裝PostgreSQL完成后，首先執行的操作之一就是調優和配置一些高級設置。可以基於系統的CPU、內存和磁盤等硬件資源，分別設置數據庫配置參數：
二、主要參數
max_connections
確定到數據庫服務器的最大並發連接數。默認情況 下，KingbaseES 允許的最大連接數相對較低，默認限制為100。這個限制與共享緩沖區的大小有關，連接利用共享緩沖區中的內存。
建議設置為預期峰值負載時需要的最大連接數。請注意，每個連接都使用shared_buffer內存，以及額外的非共享內存。一般來說，如果需要超過200個連接，就應該更多地使用連接池。請謹慎設置最大並發連接數，避免開發人員不要濫用他們的系統資源。
shared_buffers
默認情況下這個值設置得比較低。因此，更新 shared_buffers 是在大多數現代操作系統上提高整體性能最有效的設置之一。
shared_buffers 沒有特定的推薦值，但是為特定系統確定值的計算並不特別困難。一般來說，對於專用DB服務器， shared_buffers 的值應該大約是總系統RAM的30%。 另外，雖然較大的 shared_buffers 值可以在'讀繁重'用例中提高性能，但對於'寫繁重'用例，較大的 shared_buffer 值可能是有害的，因為 shared_buffers 的全部內容必須在寫期間處理。
effective_cache_size
設置規划器對查詢可用的磁盤緩存的有效大小的假設。這被考慮到基於代價的成本估計中。值越高，使用索引掃描的可能性越大，值越低，使用順序掃描的可能性越大。在設置這個參數時，應該同時考慮KingbaseES 的shared_buffers 和用於數據文件的磁盤緩存部分。另外，還要考慮不同表上並發查詢的預期數量，因為它們必須共享可用空間。該參數對PostgreSQL分配的共享內存大小沒有影響，也不保留內核磁盤緩存，它僅用於估算目的。系統也不會假設數據在查詢之間仍保留在磁盤緩存中。
建議，effective_cache_size設置系統內存 的 75%。
maintenance_work_mem
指定在維護性操作（例如VACUUM、CREATE INDEX和ALTER TABLE ADD FOREIGN KEY）中使用的 最大的內存量。其默認值是 64 兆字節（64MB）。因為在一個數據庫會話中，一個時刻只有一個這樣的操作可以被執行，並且一個數據庫安裝通常不會有太多這樣的操作並發執行， 把這個數值設置得比work_mem大很多是安全的。 更大的設置可以改進清理和恢復數據庫轉儲的性能。
注意當自動清理運行時，可能會分配最多達這個內存的 autovacuum_max_workers 倍，因此要小心不要把該默認值設置得太高，通過單獨設置autovacuum_work_mem，可能會對避免這種情況出現。將其設置為中等高值會提高vacuum和其他操作的效率。執行大型ETL操作的應用程序可能需要分配多達1/4的RAM來支持大容量真空。注意，每個autovacuum 進程可能使用這么多，所以如果使用多個autovacuum進程，您可能希望降低這個值，以便他們不能要求超過1/8或1/4的可用RAM。建議，maintenance_work_mem 通常設置為系統內存的 1/16，但是數據倉庫系統可以設置為系統內存的 1/8。
checkpoint_completion_target
檢查點期間刷新臟緩沖區所花費的時間(占檢查點間隔的百分比)。指定檢查點完成的目標，作為檢查點之間總時間的一部分。默認值是0.5（50%）。通常磁盤IO的寫入速度為300M/s-1000M/s，，在checkpoint_completion_target設置的越高的情況下，寫入速度越低，體驗越好，性能越高。反之，較低的值可能會引起I/O峰值，導致“卡死”的現象。
建議，checkpoint_completion_target可以設置為0.9（90%）。
wal_buffers
為WAL設置共享內存中的磁盤頁緩沖區的數量。默認設置-1選擇的大小等於shared_buffers的1/32(大約3%)，但不小於64kB也不大於一個WAL段的大小。
在每次事務提交時，WAL緩沖區的內容都被寫到磁盤上，所以非常大的值不太可能有顯著的好處。但是，將這個值設置為至少幾個兆字節可以提高在許多客戶機同時提交的繁忙服務器上的寫性能。在大多數情況下，由缺省設置-1選擇的自動調優應該會給出合理的結果。
在非常繁忙的高核機器上，將這個值提高到128MB是很有用的。
default_statistics_target
設置默認統計目標（直方圖數量）。
為不通過ALTER table set statistics設置列特定目標的表列設置默認統計目標。較大的值會增加ANALYZE所需的時間，但可能會提高計划者評估的質量。默認值為100。
大多數應用程序可以使用默認值100。對於非常小/簡單的數據庫，減少到10或50。數據倉庫應用程序通常需要使用500到1000。否則，在每列的基礎上增加統計目標。
random_page_cost
設置規划器對非順序獲取磁盤頁的成本的估計，默認為4.0。通過設置表空間參數，可以覆蓋特定表空間中的表和索引的這個值。
相對於seq_page_cost降低這個值將導致系統更傾向於索引掃描；提高它將使索引掃描看起來相對更昂貴。您可以同時提高或降低這兩個值，以改變磁盤I/O成本相對於CPU成本的重要性。
對機械磁盤的隨機存取通常比順序存取cost昂貴得多。但是，使用較低的默認值(4.0)，因為大多數對磁盤的隨機訪問，比如索引讀取，都假定是在緩存中。默認值可以被認為是建模隨機訪問比順序慢40倍，而預期90%的隨機讀取被緩存。如果您認為90%的緩存率對於您的工作負載是一個不正確的假設，那么您可以增加random_page_cost來更好地反映隨機存儲讀取的真實成本。相應地，如果您的數據可能完全在緩存中，例如當數據庫小於服務器總內存時，可以適當降低random_page_cost。相對於順序存儲，具有較低的隨機讀成本的存儲，例如固態硬盤，也可以使用較低的random_page_cost值進行建模，例如，1.1。
盡管系統允許將random_page_cost設置為小於seq_page_cost，但這樣做在物理上是不合理的。但是，如果數據庫完全緩存在RAM中，那么設置它們相等是有意義的，因為在這種情況下，不按順序訪問頁面不會受到負面影響。此外，在高緩存的數據庫中，應該降低這兩個值，因為獲取RAM中已經存在的頁面的成本比正常情況下要小得多。
建議，機械硬盤設置為 4, 固態硬盤設置為1.1, SAN存儲設置為1.1。
effective_io_concurrency
磁盤子系統可以有效處理的並發請求的數量，在支持的系統上，默認值為1，否則為0。通過設置表空間參數，可以覆蓋特定表空間中的表的這個值。僅適用於支持posix_fadvise的平台(例如Linux)。目前只影響並行位圖掃描的執行，但可能會影響其他I/O操作的未來版本。
但是，如果數據庫經常因為並發會話中發出的多個查詢而繁忙，那么較低的值可能足以使磁盤陣列保持忙碌。高於使磁盤繁忙所需的值只會導致額外的CPU開銷。ssd和其他基於內存的存儲通常可以處理許多並發請求，所以最好的值可能是幾百。
建議，機械硬盤設置為 2, 固態硬盤設置為 200, SAN存儲設置為 300。
work_mem
work_mem 的值用於復雜的排序操作，並定義用於中間結果(如哈希表)和排序的最大內存量。當對 work_mem 的值進行適當調優時，大多數排序操作將在更快的內存中執行，而不是讀寫磁盤。
確保' work_mem '值不要設置得太高是很重要的，因為在並行操作中，並發排序操作需要多份的' work_mem '。由於這個重要的警告，理想的做法是將' work_mem '的全局值設置為一個相對較低的值，然后修改任何特定查詢本身，以使用更高的' work_mem '值。
當查詢調用排序、哈希或任何其他需要空間分配的結構時，都會分配work_mem，每個查詢都可能發生多次。需要考慮的一件事是，不應讓可用內存在邊緣運行，避免OOM。總是需要留下某種類型的緩沖區，以防止內存使用高峰。所以work_mem中可用的最大內存應該是((RAM - shared_buffers) / (max_connections * 3) / max_parallel_workers_per_gather。
min_wal_size max_wal_size
只要WAL磁盤使用率保持在這個設置之下，舊的WAL文件就會被回收，以供將來在檢查點使用，而不是被刪除。這可以用來確保保留足夠的WAL空間來處理WAL使用的峰值，例如在運行大型批處理作業時。如果這個值沒有指定單位，它將被接受為兆字節。min_wal_size , 默認為80mb。
max_wal_size ，允許WAL在自動檢查點期間增長的最大尺寸。除非數據庫每小時寫入的數據超過1GB，在這種情況下，增加日志的大小，使其至少相當於一個小時的日志
建議：
WEB ：min_wal_size = 1GB max_wal_size = 4GB
OLTP：min_wal_size = 2GB max_wal_size = 8GB
DW ：min_wal_size = 4GB max_wal_size = 16GB
MIX ：min_wal_size = 1GB max_wal_size = 4GB
max_worker_processes
設置系統可以支持的最大后台進程數。該參數只能在服務器啟動時設置。默認值是8。
運行備用服務器時，必須將該參數設置為與主服務器相同或更高的值。否則，備用服務器將不允許查詢。
當更改此值時，請考慮同時調整max_parallel_workers、max_parallel_maintenance_workers和max_parallel_workers_per_gather。
增加到max_parallel_workers +其他workers，例如用於邏輯復制的workers和自定義后台workers。不過不會超過CPU的核數。
max_parallel_workers_per_gather
設置單個“收集”或“收集合並”節點可啟動的工作人員的最大數量。並行作業從max_worker_processes建立的進程池中獲取，受max_parallel_workers的限制。請注意，請求的worker數量可能在運行時實際上不可用。如果發生這種情況，該計划將使用比預期更少的worker運行，這可能是低效的。缺省值是2。將此值設置為0將禁用並行查詢執行。
請注意，並行查詢可能比非並行查詢消耗更多的資源，因為每個工作進程是完全獨立的進程，它對系統的影響與額外的用戶會話大致相同。在為該設置選擇值時，以及在配置其他控制資源利用率的設置(如work_mem)時，都應該考慮到這一點。資源限制(如work_mem)單獨應用於每個worker，這意味着所有進程的總利用率可能比通常情況下任何單個進程的總利用率要高得多。例如，使用4個worker的並行查詢使用的CPU時間、內存、I/O帶寬等可能是完全不使用worker的查詢的5倍。
計划使用並行查詢，建議增加到4或8，這取決於核心/並發會話。
max_parallel_workers
設置系統可支持並行操作的最大worker數。缺省值為8。當增加或減少這個值時，也考慮調整max_parallel_maintenance_workers和max_parallel_workers_per_gather。另外，請注意，該值的設置高於max_worker_processes將不會產生影響，因為並行工作進程是從該設置建立的工作進程池中獲取的。
如果您認為可以從並行查詢，在DW系統中，設置為CPU核心數。
max_parallel_maintenance_workers
設置單一工具性命令能夠啟動的並行工作者的最大數目。當前，唯一一種支持使用並行工作者的工具性命令是`CREATE INDEX`，並且只有在構建B-樹索引時才能並行。並行工作者從由[max_worker_processes] 創建的進程池中取出，數量由[max_parallel_workers] 控制。注意實際在運行時所請求數量的工作者可能不可用。如果發生這種情況，工具性操作將使用比預期數量少的工作者運行。默認值為2。將這個值設置為0可以禁用工具性命令對並行工作者的使用。
注意並行工具性命令不應該消耗比同等數量非並行操作更多的內存。這種策略與並行查詢不同，並行查詢的資源限制通常是應用在每個工作者進程上。並行工具性命令把資源限制`maintenance_work_mem`當作對整個工具性命令的限制，而不管其中用到了多少個並行工作者進程。不過，並行工具性命令實際上可能仍會消耗更多的CPU資源和I/O帶寬。
計划使用並行查詢，建議增加到4或8，這取決於核心/並發會話。