shared_buffers (integer) #設定資料庫伺服器用於共享記憶體緩衝區的記憶體量。預設值通常為 128 MB (128MB)，但如果您的核心設定不支援（在 initdb 期間確定），則可能更少。此設定必須至少為 128 KB。但是，通常需要明顯高於最小值的設定才能獲得良好的效能。如果未指定單位，則此值將被視為區塊，即 BLCKSZ 位元組，通常為 8kB。（非預設的 BLCKSZ 值會更改最小值。）此參數只能在伺服器啟動時設定。
如果您有一台專用的資料庫伺服器，具有 1GB 或更多的 RAM，則 shared_buffers 的合理起始值為系統中記憶體的 25%。在某些工作負載下，即使更大的 shared_buffers 設定也有效，但由於 PostgreSQL 也依賴作業系統快取，因此將超過 40% 的 RAM 分配給 shared_buffers 不太可能比更小的量更好。較大的 shared_buffers 設定通常需要在 max_wal_size 中相應地增加，以便將大量新增或變更資料的寫入過程分散到更長的時間內。
在 RAM 小於 1GB 的系統上，較小的 RAM 百分比是合適的，以便為作業系統留下足夠的空間。
huge_pages (enum) #控制是否為主要共享記憶體區域請求巨頁 (huge pages)。有效值為 try（預設值）、on 和 off。將 huge_pages 設定為 try 時，伺服器將嘗試請求巨頁，但如果失敗，則會回復為預設值。設定為 on 時，請求巨頁失敗將阻止伺服器啟動。設定為 off 時，將不會請求巨頁。巨頁的實際狀態由伺服器變數 huge_pages_status 指示。
目前，此設定僅在 Linux 和 Windows 上受支援。當設定為 try 時，在其他系統上會忽略此設定。在 Linux 上，僅當 shared_memory_type 設定為 mmap（預設值）時才支援此設定。
使用巨頁會導致較小的頁表和較少的 CPU 時間用於記憶體管理，從而提高效能。有關在 Linux 上使用巨頁的更多詳細資訊，請參閱 第 18.4.5 節。
在 Windows 上，巨頁稱為大型頁面。要使用它們，您需要將使用者權限 「在記憶體中鎖定頁面」 分配給執行 PostgreSQL 的 Windows 使用者帳戶。您可以使用 Windows 群組原則工具 (gpedit.msc) 分配使用者權限 「在記憶體中鎖定頁面」。要將資料庫伺服器作為獨立程序在命令提示字元中啟動，而不是作為 Windows 服務啟動，則必須以管理員身份執行命令提示字元，或者必須停用使用者帳戶控制 (UAC)。啟用 UAC 後，正常的命令提示字元會在啟動時撤銷使用者權限 「在記憶體中鎖定頁面」。
請注意，此設定僅影響主要共享記憶體區域。Linux、FreeBSD 和 Illumos 等作業系統也可以自動使用巨頁（也稱為 “超級” 頁面或 “大型” 頁面）進行正常的記憶體分配，而無需 PostgreSQL 的明確請求。在 Linux 上，這稱為 “透明巨頁” (THP)。已知該功能會導致某些 Linux 版本上的 PostgreSQL 效能下降，因此目前不建議使用（與明確使用 huge_pages 不同）。
huge_page_size (integer) #控制巨頁的大小，當使用 huge_pages 啟用巨頁時。預設值為零（0）。當設定為 0 時，將使用系統上的預設巨頁大小。此參數只能在伺服器啟動時設定。
現代 64 位元伺服器架構上一些常見的頁面大小包括：2MB 和 1GB (Intel 和 AMD)、16MB 和 16GB (IBM POWER)，以及 64kB、2MB、32MB 和 1GB (ARM)。有關使用和支援的更多資訊，請參閱第 18.4.5 節。
目前僅 Linux 支援非預設設定。
temp_buffers (integer) #設定每個資料庫會話中用於臨時緩衝區的最大記憶體量。這些是會話本地的緩衝區，僅用於存取臨時表。如果此值未指定單位，則將其視為區塊，即 BLCKSZ 位元組，通常為 8kB。預設值為八百萬位元組（8MB）。（如果 BLCKSZ 不是 8kB，則預設值會按比例縮放。）可以在個別會話中更改此設定，但只能在會話中第一次使用臨時表之前；隨後嘗試更改該值將不會對該會話產生任何影響。
會話將根據需要分配臨時緩衝區，直到達到 temp_buffers 給定的限制。在實際上不需要太多臨時緩衝區的會話中設置大值的成本僅為一個緩衝區描述符，或者每次增加 temp_buffers 約 64 個位元組。但是，如果實際使用了一個緩衝區，則將為其消耗額外的 8192 個位元組（通常為 BLCKSZ 個位元組）。
max_prepared_transactions (integer) #設定可以同時處於「已預備 (prepared)」狀態的事務的最大數量（請參閱 PREPARE TRANSACTION）。將此參數設定為零（預設值）會停用已預備事務功能。此參數只能在伺服器啟動時設定。
如果您不打算使用已預備事務，則應將此參數設定為零，以防止意外建立已預備事務。如果您正在使用已預備事務，則您可能希望 max_prepared_transactions 至少與 max_connections 一樣大，以便每個會話都可以有一個待處理的已預備事務。
執行備用伺服器時，您必須將此參數設定為與主伺服器相同或更高的值。否則，不允許在備用伺服器中執行查詢。
work_mem (integer) #設定查詢操作（例如排序或雜湊表）在寫入臨時磁碟檔案之前使用的最大記憶體量的基本值。如果此值未指定單位，則將其視為 KB。預設值為四百萬位元組（4MB）。請注意，一個複雜的查詢可能會同時執行多個排序和雜湊操作，通常每個操作都允許使用與此值指定的記憶體一樣多的記憶體，然後才開始將資料寫入臨時檔案。此外，多個正在運行的會話可能會同時執行此類操作。因此，使用的總記憶體可能是 work_mem 值的多倍；在選擇該值時，必須牢記這一點。排序操作用於 ORDER BY、DISTINCT 和合併聯結。雜湊表用於雜湊聯結、基於雜湊的聚合、記憶節點以及基於雜湊的 IN 子查詢處理。
與等效的基於排序的操作相比，基於雜湊的操作通常對記憶體可用性更敏感。雜湊表的記憶體限制是通過將 work_mem 乘以 hash_mem_multiplier 來計算的。這使得基於雜湊的操作可以使用超過通常 work_mem 基本量的記憶體量。
hash_mem_multiplier (floating point) #用於計算基於雜湊的操作可以使用的最大記憶體量。最終限制由 work_mem 乘以 hash_mem_multiplier 確定。預設值為 2.0，這使得基於雜湊的操作使用兩倍於通常 work_mem 的基本量。
在查詢操作經常發生溢出的環境中，請考慮增加 hash_mem_multiplier，尤其是當僅僅增加 work_mem 會導致記憶體壓力時（記憶體壓力通常以間歇性的記憶體不足錯誤的形式出現）。預設設定 2.0 通常對混合工作負載有效。在 work_mem 已經增加到 40MB 或更多的環境中，更高的設定（2.0 - 8.0 或更多）可能有效。
maintenance_work_mem (integer) #指定維護操作（例如 VACUUM、CREATE INDEX 和 ALTER TABLE ADD FOREIGN KEY）使用的最大記憶體量。如果此值未指定單位，則將其視為 KB。預設值為 64 百萬位元組（64MB）。由於資料庫會話一次只能執行其中一個操作，並且安裝通常不會同時運行很多這些操作，因此將此值設定為明顯大於 work_mem 是安全的。較大的設定可能會提高清理和還原資料庫轉儲的效能。
請注意，當自動清理執行時，可能會分配高達 autovacuum_max_workers 倍的記憶體，因此請注意不要將預設值設定得太高。通過單獨設定 autovacuum_work_mem 來控制這一點可能會很有用。
autovacuum_work_mem (integer) #指定每個自動清理工作行程可使用的最大記憶體量。如果未指定單位，則以 KB 為單位。預設值為 -1，表示應改用 maintenance_work_mem 的值。此設定對在其他環境中執行的 VACUUM 的行為沒有影響。此參數只能在 postgresql.conf 檔案或伺服器命令列中設定。
vacuum_buffer_usage_limit (integer) #指定 VACUUM 和 ANALYZE 指令使用的Buffer Access Strategy的大小。設定為 0 將允許操作使用任意數量的 shared_buffers。有效的範圍從 128 kB 到 16 GB。如果指定的大小超過 shared_buffers 的 1/8，則大小將會被靜默地限制為該值。預設值為 2MB。如果未指定單位，則以 KB 為單位。此參數可以在任何時候設定。可以透過傳遞 BUFFER_USAGE_LIMIT 選項來覆寫 VACUUM 和 ANALYZE。較高的設定可以使 VACUUM 和 ANALYZE 執行得更快，但是設定過大可能會導致過多的其他有用頁面從共享緩衝區中逐出。
logical_decoding_work_mem (integer) #指定在將一些已解碼的變更寫入本地磁碟之前，邏輯解碼使用的最大記憶體量。這限制了邏輯串流複寫連線使用的記憶體量。預設值為 64 MB (64MB)。由於每個複寫連線只使用一個此大小的緩衝區，並且安裝通常不會同時有許多這樣的連線（受 max_wal_senders 限制），因此將此值設定為明顯高於 work_mem 是安全的，從而減少了寫入磁碟的已解碼變更量。
commit_timestamp_buffers (integer) #指定用於快取 pg_commit_ts 內容的記憶體量（請參閱表 65.1）。如果未指定單位，則以區塊為單位，即 BLCKSZ 位元組，通常為 8kB。預設值為 0，這會請求 shared_buffers/512，最多 1024 個區塊，但不少於 16 個區塊。此參數只能在伺服器啟動時設定。
multixact_member_buffers (integer) #指定用於快取 pg_multixact/members 內容的共享記憶體量（請參閱表 65.1）。如果未指定單位，則以區塊為單位，即 BLCKSZ 位元組，通常為 8kB。預設值為 32。此參數只能在伺服器啟動時設定。
multixact_offset_buffers (integer) #指定用於快取 pg_multixact/offsets 內容的共享記憶體量（請參閱表 65.1）。如果未指定單位，則以區塊為單位，即 BLCKSZ 位元組，通常為 8kB。預設值為 16。此參數只能在伺服器啟動時設定。
notify_buffers (integer) #指定用於快取 pg_notify 內容的共享記憶體量（請參閱表 65.1）。如果未指定單位，則以區塊為單位，即 BLCKSZ 位元組，通常為 8kB。預設值為 16。此參數只能在伺服器啟動時設定。
serializable_buffers (integer) #指定用於快取 pg_serial 內容的共享記憶體量（請參閱表 65.1）。如果未指定單位，則以區塊為單位，即 BLCKSZ 位元組，通常為 8kB。預設值為 32。此參數只能在伺服器啟動時設定。
subtransaction_buffers (integer) #指定用於快取 pg_subtrans 內容的共享記憶體量（請參閱表 65.1）。如果未指定單位，則以區塊為單位，即 BLCKSZ 位元組，通常為 8kB。預設值為 0，這會請求 shared_buffers/512，最多 1024 個區塊，但不少於 16 個區塊。此參數只能在伺服器啟動時設定。
transaction_buffers (integer) #指定用於快取 pg_xact 內容的共享記憶體量（請參閱表 65.1）。如果未指定單位，則以區塊為單位，即 BLCKSZ 位元組，通常為 8kB。預設值為 0，這會請求 shared_buffers/512，最多 1024 個區塊，但不少於 16 個區塊。此參數只能在伺服器啟動時設定。
max_stack_depth (integer) #指定伺服器執行堆疊的最大安全深度。此參數的理想設定是核心強制執行的實際堆疊大小限制（由 ulimit -s 或本地等效項設定），減去約一百萬位元組左右的安全邊際。需要安全邊際，因為堆疊深度並非在伺服器中的每個例程中都檢查，而僅在關鍵的潛在遞迴例程中檢查。如果未指定單位，則以 KB 為單位。預設設定為 2 MB (2MB)，這是保守的小設定，不太可能冒崩潰的風險。但是，它可能太小而無法執行複雜的函數。只有超級使用者和具有適當 SET 權限的使用者才能更改此設定。
若將 max_stack_depth 設定為高於實際核心限制的值，代表失控的遞迴函式可能會導致個別後端程序崩潰。在 PostgreSQL 可以判斷核心限制的平台上，伺服器將不允許將此變數設定為不安全的值。但是，並非所有平台都提供此資訊，因此建議在選擇值時謹慎。
shared_memory_type (enum) #指定伺服器應用於主要共享記憶體區域的共享記憶體實作，該區域保存 PostgreSQL 的共享緩衝區和其他共享資料。可能的值包括 mmap（用於使用 mmap 分配的匿名共享記憶體）、sysv（用於透過 shmget 分配的 System V 共享記憶體）和 windows（用於 Windows 共享記憶體）。並非所有值都受所有平台支援；第一個受支援的選項是該平台的預設值。通常不建議使用 sysv 選項（它不是任何平台的預設選項），因為它通常需要非預設的核心設定才能允許大量分配（請參閱第 18.4.1 節）。
dynamic_shared_memory_type (enum) #指定伺服器應使用的動態共享記憶體實作。可能的值包括 posix（用於使用 shm_open 分配的 POSIX 共享記憶體）、sysv（用於透過 shmget 分配的 System V 共享記憶體）、windows（用於 Windows 共享記憶體）和 mmap（用於模擬使用儲存在資料目錄中的記憶體映射檔案的共享記憶體）。並非所有值都受所有平台支援；第一個受支援的選項通常是該平台的預設選項。通常不建議使用 mmap 選項（它不是任何平台的預設選項），因為作業系統可能會重複將修改後的頁面寫回磁碟，從而增加系統 I/O 負載；但是，當 pg_dynshmem 目錄儲存在 RAM 磁碟上，或者當其他共享記憶體設備不可用時，它可能對除錯有用。
min_dynamic_shared_memory (integer) #指定在伺服器啟動時應分配的記憶體量，以供平行查詢使用。當這個記憶體區域不足或被並行查詢耗盡時，新的平行查詢會嘗試使用 dynamic_shared_memory_type 配置的方法，從作業系統臨時分配額外的共享記憶體，由於記憶體管理開銷，這可能會比較慢。使用 min_dynamic_shared_memory 在啟動時分配的記憶體會受到作業系統上 huge_pages 設定的影響（在支援的情況下），並且在作業系統自動管理的情況下，可能更容易從更大的頁面中受益。預設值為 0（無）。此參數只能在伺服器啟動時設定。
temp_file_limit (integer) #指定一個程序可以使用的臨時檔案（例如排序和雜湊臨時檔案，或持有游標的儲存檔案）的最大磁碟空間量。嘗試超過此限制的交易將會取消。如果此值在指定時沒有單位，則視為 KB。-1（預設值）表示沒有限制。只有超級使用者和具有適當 SET 權限的使用者才能變更此設定。
此設定限制給定的 PostgreSQL 程序在任何時刻使用的所有臨時檔案的總空間。應注意的是，用於明確臨時表格的磁碟空間（與查詢執行在後台使用的臨時檔案相對）不計入此限制。
max_notify_queue_pages (integer) #指定 NOTIFY / LISTEN 佇列允許分配的最大頁數。預設值為 1048576。對於 8 KB 的頁面，它允許使用高達 8 GB 的磁碟空間。
max_files_per_process (integer) #設定每個伺服器子程序允許同時開啟的最大檔案數量。預設值為一千個檔案。如果核心正在強制執行安全的每程序限制，則您無需擔心此設定。但是在某些平台上（尤其是大多數 BSD 系統），如果許多程序都嘗試開啟那麼多檔案，核心將允許個別程序開啟比系統實際支援的更多的檔案。如果您發現自己看到 “Too many open files” 失敗，請嘗試降低此設定。此參數只能在伺服器啟動時設定。
在執行 VACUUM 和 ANALYZE 指令期間，系統會維護一個內部計數器，用於追蹤執行的各種 I/O 操作的估計成本。當累積成本達到限制（由 vacuum_cost_limit 指定）時，執行操作的程序將休眠一段時間，如 vacuum_cost_delay 所指定。然後它將重設計數器並繼續執行。
此功能的目的是允許管理員減少這些指令對並行資料庫活動的 I/O 影響。在許多情況下，像 VACUUM 和 ANALYZE 這樣的維護指令是否快速完成並不重要；但是，通常非常重要的是，這些指令不會顯著干擾系統執行其他資料庫操作的能力。基於成本的 vacuum 延遲為管理員提供了一種實現此目的的方法。
對於手動發出的 VACUUM 指令，此功能預設為停用。若要啟用它，請將 vacuum_cost_delay 變數設定為非零值。
vacuum_cost_delay (floating point) #當成本限制被超過時，程序將休眠的時間量。如果此值在指定時沒有單位，則視為毫秒。預設值為零，這會停用基於成本的 vacuum 延遲功能。正值啟用基於成本的 vacuum。
使用基於成本的 vacuum 時，vacuum_cost_delay 的適當值通常非常小，可能小於 1 毫秒。雖然 vacuum_cost_delay 可以設定為小數毫秒值，但在較舊的平台上可能無法準確測量此類延遲。在此類平台上，將 VACUUM 的節流資源消耗量增加到超過 1 毫秒所獲得的值，將需要變更其他 vacuum 成本參數。儘管如此，您應該保持 vacuum_cost_delay 儘可能小，以便您的平台可以一致地測量；大的延遲沒有幫助。
vacuum_cost_page_hit (integer) #在共享緩衝區快取中找到的緩衝區進行清理的預估成本。 它表示鎖定緩衝池、查找共享雜湊表和掃描頁面內容的成本。 預設值為 1。
vacuum_cost_page_miss (integer) #必須從磁碟讀取的緩衝區進行清理的預估成本。 這表示鎖定緩衝池、查找共享雜湊表、從磁碟讀取所需的區塊以及掃描其內容的工作量。 預設值為 2。
vacuum_cost_page_dirty (integer) #當清理程序修改先前為乾淨的區塊時收取的預估成本。 它表示將髒區塊再次刷新到磁碟所需的額外 I/O。 預設值為 20。
vacuum_cost_limit (integer) #這是累積成本，它將導致清理程序休眠 vacuum_cost_delay。 預設值為 200。
有些操作會持有關鍵鎖，因此應儘快完成。基於成本的清理延遲不會在這些操作期間發生。 因此，成本累積可能會遠高於指定的限制。 為避免在這種情況下產生無用的長時間延遲，實際延遲計算為 vacuum_cost_delay * accumulated_balance / vacuum_cost_limit，最大值為 vacuum_cost_delay * 4。
有一個單獨的伺服器程序稱為背景寫入程序，其功能是發出「髒」（新的或修改過的）共享緩衝區的寫入。 當乾淨的共享緩衝區數量似乎不足時，背景寫入程序會將一些髒緩衝區寫入檔案系統並將其標記為乾淨。 這降低了處理使用者查詢的伺服器程序無法找到乾淨的緩衝區並且必須自己寫入髒緩衝區的可能性。 然而，背景寫入程序確實導致 I/O 負載的淨整體增加，因為雖然重複變髒的頁面否則可能每個檢查點間隔只寫入一次，但背景寫入程序可能會在同一間隔中多次寫入它。 本小節中討論的參數可用於根據本地需求調整行為。
bgwriter_delay (integer) #指定背景寫入程序活動輪次之間的延遲。 在每一輪中，寫入程序會寫入一定數量的髒緩衝區（可由以下參數控制）。 然後它會休眠 bgwriter_delay 的時間長度，然後重複。 但是，當緩衝池中沒有髒緩衝區時，無論 bgwriter_delay 如何，它都會進入更長的休眠狀態。 如果未指定單位，則此值以毫秒為單位。 預設值為 200 毫秒 (200ms)。 請注意，在某些系統上，休眠延遲的有效解析度為 10 毫秒； 將 bgwriter_delay 設定為非 10 的倍數的值可能與將其設定為下一個較高的 10 的倍數的結果相同。 此參數只能在 postgresql.conf 檔案或伺服器命令列上設定。
bgwriter_lru_maxpages (integer) #在每一輪中，背景寫入程序將寫入不超過這麼多的緩衝區。 將此設定為零會停用背景寫入。 （請注意，檢查點由單獨的、專用的輔助程序管理，不受影響。） 預設值為 100 個緩衝區。 此參數只能在 postgresql.conf 檔案或伺服器命令列上設定。
bgwriter_lru_multiplier (floating point) #每一輪中寫入的髒緩衝區數量基於最近幾輪中伺服器程序需要的新緩衝區數量。 最近的平均需求乘以 bgwriter_lru_multiplier 以得出下一輪中需要的緩衝區數量的估計值。 寫入髒緩衝區，直到有那麼多乾淨、可重複使用的緩衝區可用。 （但是，每輪寫入的緩衝區不會超過 bgwriter_lru_maxpages。） 因此，設定為 1.0 表示「及時」的策略，即精確寫入預測需要的緩衝區數量。 較大的值提供了一些緩衝，以防止需求激增，而較小的值則有意將寫入留給伺服器程序完成。 預設值為 2.0。 此參數只能在 postgresql.conf 檔案或伺服器命令列上設定。
bgwriter_flush_after (integer) #每當背景寫入程序寫入超過此數量的資料時，請嘗試強制作業系統將這些寫入發送到基礎儲存。 這樣做會限制核心頁面快取中的髒資料量，從而降低在檢查點結束時發出 fsync 時，或當作業系統在後台以較大批次寫回資料時，發生停頓的可能性。 通常，這將大大減少交易延遲，但也有一些情況，尤其是在工作負載大於 shared_buffers 但小於作業系統頁面快取的情況下，效能可能會降低。 此設定可能在某些平台上沒有任何作用。 如果未指定單位，則此值以區塊為單位，即 BLCKSZ 個位元組，通常為 8kB。 有效範圍介於 0（停用強制寫回）和 2MB 之間。 預設值在 Linux 上為 512kB，在其他地方為 0。 （如果 BLCKSZ 不是 8kB，則預設值和最大值會按比例縮放。） 此參數只能在 postgresql.conf 檔案或伺服器命令列上設定。
較小的 bgwriter_lru_maxpages 和 bgwriter_lru_multiplier 值會減少背景寫入程序造成的額外 I/O 負載，但也更容易讓伺服器程序必須自行發出寫入請求，從而延遲互動式查詢。
backend_flush_after (integer) #每當單一後端寫入超過此數量的資料時，嘗試強制作業系統將這些寫入操作發送到基礎儲存裝置。這樣做將限制核心頁面快取中的髒資料量，從而降低在檢查點結束時發出 fsync 時或作業系統在背景中以較大批次寫回資料時發生停頓的可能性。通常，這會大大降低事務延遲，但在某些情況下，尤其是在工作負載大於 shared_buffers，但小於作業系統頁面快取的情況下，效能可能會降低。此設定可能對某些平台沒有影響。如果未指定單位，則此值被視為區塊，即 BLCKSZ 位元組，通常為 8kB。有效範圍介於 0（停用強制寫回）和 2MB 之間。預設值為 0，即不強制寫回。（如果 BLCKSZ 不是 8kB，則最大值會按比例縮放。）
effective_io_concurrency (integer) #設定 PostgreSQL 預期可以同時執行的並行磁碟 I/O 操作數量。 提高此值將增加任何單一 PostgreSQL 工作階段嘗試平行啟動的 I/O 操作數量。 允許的範圍是 1 到 1000，或零以停用非同步 I/O 請求的發出。 目前，此設定僅影響位元圖堆積掃描。
對於磁碟機，此設定的一個良好的起點是組成 RAID 0 條帶或用於資料庫的 RAID 1 鏡像的獨立磁碟機數量。（對於 RAID 5，不應計算同位檢查磁碟機。）但是，如果資料庫經常忙於在並行工作階段中發出的多個查詢，則較低的值可能足以使磁碟陣列保持忙碌。高於保持磁碟忙碌所需的值只會導致額外的 CPU 額外負荷。 SSD 和其他基於記憶體的儲存裝置通常可以處理許多並行請求，因此最佳值可能在數百個範圍內。
非同步 I/O 取決於有效的 posix_fadvise 函數，某些作業系統缺少該函數。如果該函數不存在，則將此參數設定為零以外的任何值都會導致錯誤。在某些作業系統（例如 Solaris）上，該函數存在但實際上沒有執行任何操作。
在支援的系統上，預設值為 1，否則為 0。 可以透過設定同名的表空間參數來覆寫特定表空間中表格的此值（請參閱ALTER TABLESPACE）。
maintenance_io_concurrency (integer) #與 effective_io_concurrency 類似，但用於代表許多客戶端工作階段完成的維護工作。
在支援的系統上，預設值為 10，否則為 0。 可以透過設定同名的表空間參數來覆寫特定表空間中表格的此值（請參閱ALTER TABLESPACE）。
io_combine_limit (integer) #控制合併 I/O 操作中的最大 I/O 大小。 預設值為 128kB。
max_worker_processes (integer) #設定叢集可以支援的背景處理程序的最大數量。 此參數只能在伺服器啟動時設定。 預設值為 8。
執行備用伺服器時，您必須將此參數設定為與主伺服器相同或更高的值。否則，不允許在備用伺服器中執行查詢。
變更此值時，請考慮同時調整 max_parallel_workers、max_parallel_maintenance_workers 和 max_parallel_workers_per_gather。
max_parallel_workers_per_gather (integer) #設定單一 Gather 或 Gather Merge 節點可以啟動的最大工作程序數量。 平行工作程序取自 max_worker_processes 建立的處理程序池，並受 max_parallel_workers 限制。 請注意，請求的工作程序數量可能在執行階段實際上無法使用。 如果發生這種情況，計畫將以少於預期的工作程序數量執行，這可能效率不高。 預設值為 2。 將此值設定為 0 會停用平行查詢執行。
請注意，平行查詢可能比非平行查詢消耗更多的資源，因為每個工作程序處理程序都是一個完全獨立的處理程序，它對系統的影響大致與額外的使用者工作階段相同。 在選擇此設定的值時，以及在設定控制資源利用率的其他設定（例如 work_mem）時，應考慮到這一點。 資源限制（例如 work_mem）會分別套用到每個工作程序，這表示所有處理程序中的總利用率可能比任何單一處理程序通常的利用率高得多。 例如，使用 4 個工作程序的平行查詢可能消耗高達 5 倍的 CPU 時間、記憶體、I/O 頻寬等，而不是根本不使用工作程序的查詢。
有關平行查詢的更多資訊，請參閱第 15 章。
max_parallel_maintenance_workers (integer) #設定單一實用程式命令可以啟動的最大平行工作程序數量。 目前，支援使用平行工作程序的平行實用程式命令是 CREATE INDEX（僅在建立 B-tree 索引時）和 VACUUM（不含 FULL 選項）。 平行工作程序取自 max_worker_processes 建立的處理程序池，並受 max_parallel_workers 限制。 請注意，請求的工作程序數量可能在執行階段實際上無法使用。 如果發生這種情況，實用程式操作將以少於預期的工作程序數量執行。 預設值為 2。 將此值設定為 0 會停用實用程式命令對平行工作程序的使用。
請注意，平行實用程式命令不應消耗比等效的非平行操作多太多的記憶體。 這種策略與平行查詢的策略不同，在平行查詢中，資源限制通常適用於每個工作程序處理程序。 平行實用程式命令將資源限制 maintenance_work_mem 視為適用於整個實用程式命令的限制，而與平行工作程序處理程序的數量無關。 但是，平行實用程式命令可能仍然會消耗更多的 CPU 資源和 I/O 頻寬。
max_parallel_workers (integer) #設定叢集可支援平行作業的最大工作者數量。預設值為 8。在增加或減少此值時，也請考慮調整max_parallel_maintenance_workers和max_parallel_workers_per_gather。此外，請注意，如果此值的設定高於max_worker_processes，則不會有任何效果，因為平行工作者是從該設定建立的工作者程序池中取得的。
parallel_leader_participation (boolean) #允許領導者程序在 Gather 和 Gather Merge 節點下執行查詢計畫，而不是等待工作者程序。預設值為 on。將此值設定為 off 可降低工作者被封鎖的可能性，因為領導者讀取元組的速度不夠快，但需要領導者程序等待工作者程序啟動後才能產生第一個元組。領導者可以幫助或阻礙效能的程度取決於計畫類型、工作者數量和查詢持續時間。
如果您在文件中看到任何不正確、與您使用特定功能時的體驗不符或需要進一步澄清的地方，請使用此表單來報告文件問題。