shared_buffers
(integer
) #設定資料庫伺服器用於共享記憶體緩衝區的記憶體量。預設值通常是 128MB,但在 initdb 過程中,如果核心設定不支援,則可能更少。此設定必須至少為 128KB。然而,為了獲得良好的效能,通常需要遠大於最小值的設定。如果此值未指定單位,則假定為塊,即 BLCKSZ
位元組,通常為 8KB。(BLCKSZ
的非預設值會改變最小值。)此引數只能在伺服器啟動時設定。
如果您有 1GB 或更多 RAM 的專用資料庫伺服器,shared_buffers
的合理起始值是系統記憶體的 25%。對於某些工作負載,即使是更大的 shared_buffers
設定也可能有效,但由於 PostgreSQL 也依賴於作業系統快取,因此將超過 40% 的 RAM 分配給 shared_buffers
不可能比分配較少量的 RAM 效果更好。較大的 shared_buffers
設定通常需要相應地增加 max_wal_size
,以將大量新資料或已更改資料的寫入過程分散到更長的時間段內。
在 RAM 少於 1GB 的系統上,分配較小比例的 RAM 是合適的,以便為作業系統留出足夠的空間。
huge_pages
(enum
) #控制是否為主共享記憶體區域請求大頁。有效值包括 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 等作業系統也可以自動為普通記憶體分配使用大頁(也稱為“super”頁或“large”頁),而無需 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
) #同時設定可以處於“準備好”狀態(請參閱 PREPARE TRANSACTION)的事務的最大數量。將此引數設定為零(這是預設值)將停用準備事務功能。此引數只能在伺服器啟動時設定。
如果您不打算使用準備事務,則應將此引數設定為零,以防止意外建立準備事務。如果您正在使用準備事務,您可能希望 max_prepared_transactions
至少與 max_connections 一樣大,以便每個會話都可以有一個待處理的準備事務。
執行備用伺服器時,必須將此引數設定為與主伺服器相同或更高的值。否則,將不允許在備用伺服器上執行查詢。
work_mem
(integer
) #設定查詢操作(如排序或雜湊表)在寫入臨時磁碟檔案之前使用的最大記憶體量。如果此值未指定單位,則假定為千位元組。預設值為 4MB。請注意,複雜的查詢可能同時執行多個排序和雜湊操作,每個操作通常允許使用此值指定的記憶體量,然後才開始將資料寫入臨時檔案。此外,多個正在執行的會話可以同時執行此類操作。因此,總記憶體使用量可能是 work_mem
值的許多倍;在選擇值時必須牢記這一點。排序操作用於 ORDER BY
、DISTINCT
和合並聯接。雜湊表用於雜湊聯接、基於雜湊的聚合、memoize 節點和基於雜湊的 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
)的最大記憶體量。如果此值未指定單位,則假定為千位元組。預設值為 64MB。由於每個資料庫會話一次只能執行其中一項操作,並且一個安裝通常不會同時執行許多此類操作,因此將此值設定得遠大於 work_mem
是安全的。較大的設定可能會提高 vacuuming 和還原資料庫轉儲的效能。
請注意,當 autovacuum 執行時,可能會分配多達 autovacuum_max_workers 倍的此記憶體,因此請小心不要將預設值設定得太高。透過單獨設定 autovacuum_work_mem 來控制這一點可能很有用。
autovacuum_work_mem
(integer
) #指定每個 autovacuum 工作程序使用的最大記憶體量。如果此值未指定單位,則假定為千位元組。預設值為 -1,表示應使用 maintenance_work_mem 的值。此設定不會影響 VACUUM
在其他上下文中的行為。此引數只能在 postgresql.conf
檔案中或在伺服器命令列中設定。
vacuum_buffer_usage_limit
(integer
) #VACUUM
和 ANALYZE
命令使用的 緩衝區訪問策略的大小。設定為 0
將允許操作使用任意數量的 shared_buffers
。否則,有效大小範圍為 128KB 到 16GB。如果指定的尺寸超過 shared_buffers
的 1/8,尺寸將被悄悄限制在該值。預設值為 2MB。如果此值未指定單位,則假定為千位元組。此引數可隨時設定。在傳遞 BUFFER_USAGE_LIMIT
選項時,可以為 VACUUM 和 ANALYZE 覆蓋。較高的設定可以使 VACUUM
和 ANALYZE
執行得更快,但設定過大可能會導致太多有用的頁面從共享緩衝區中被逐出。
logical_decoding_work_mem
(integer
) #指定邏輯解碼使用的最大記憶體量,然後將部分解碼的更改寫入本地磁碟。這限制了邏輯流複製連線使用的記憶體量。預設值為 64MB。由於每個複製連線僅使用一個此類大小的緩衝區,並且一個安裝通常沒有多少此類併發連線(受 max_wal_senders
限制),因此將此值設定得遠高於 work_mem
是安全的,從而減少寫入磁碟的解碼更改量。
commit_timestamp_buffers
(integer
) #指定用於快取 pg_commit_ts
內容的記憶體量(請參閱 表 66.1)。如果此值未指定單位,則假定為塊,即 BLCKSZ
位元組,通常為 8KB。預設值為 0
,它請求 shared_buffers
/512,最多 1024 個塊,但不少於 16 個塊。此引數只能在伺服器啟動時設定。
multixact_member_buffers
(integer
) #指定用於快取 pg_multixact/members
內容的共享記憶體量(請參閱 表 66.1)。如果此值未指定單位,則假定為塊,即 BLCKSZ
位元組,通常為 8KB。預設值為 32。此引數只能在伺服器啟動時設定。
multixact_offset_buffers
(integer
) #指定用於快取 pg_multixact/offsets
內容的共享記憶體量(請參閱 表 66.1)。如果此值未指定單位,則假定為塊,即 BLCKSZ
位元組,通常為 8KB。預設值為 16。此引數只能在伺服器啟動時設定。
notify_buffers
(integer
) #指定用於快取 pg_notify
內容的共享記憶體量(請參閱 表 66.1)。如果此值未指定單位,則假定為塊,即 BLCKSZ
位元組,通常為 8KB。預設值為 16。此引數只能在伺服器啟動時設定。
serializable_buffers
(integer
) #指定用於快取 pg_serial
內容的共享記憶體量(請參閱 表 66.1)。如果此值未指定單位,則假定為塊,即 BLCKSZ
位元組,通常為 8KB。預設值為 32。此引數只能在伺服器啟動時設定。
subtransaction_buffers
(integer
) #指定用於快取 pg_subtrans
內容的共享記憶體量(請參閱 表 66.1)。如果此值未指定單位,則假定為塊,即 BLCKSZ
位元組,通常為 8KB。預設值為 0
,它請求 shared_buffers
/512,最多 1024 個塊,但不少於 16 個塊。此引數只能在伺服器啟動時設定。
transaction_buffers
(integer
) #指定用於快取 pg_xact
內容的共享記憶體量(請參閱 表 66.1)。如果此值未指定單位,則假定為塊,即 BLCKSZ
位元組,通常為 8KB。預設值為 0
,它請求 shared_buffers
/512,最多 1024 個塊,但不少於 16 個塊。此引數只能在伺服器啟動時設定。
max_stack_depth
(integer
) #指定伺服器執行堆疊的最大安全深度。此引數的理想設定是核心強制執行的實際堆疊大小限制(由 ulimit -s
或本地等效命令設定),減去大約一兆位元組的安全餘量。之所以需要安全餘量,是因為堆疊深度並非在伺服器的每個例程中都進行檢查,而僅在關鍵的潛在遞迴例程中進行檢查。如果此值未指定單位,則假定為千位元組。預設設定是兩兆位元組(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
) #指定程序可以為臨時檔案(如排序和雜湊臨時檔案,或暫存遊標的儲存檔案)使用的最大磁碟空間量。嘗試超出此限制的事務將被取消。如果此值未指定單位,則假定為千位元組。-1(預設值)表示沒有限制。只有超級使用者和具有適當 SET
許可權的使用者才能更改此設定。
此設定限制了給定 PostgreSQL 程序在任何時刻用於所有臨時檔案的總空間。應注意,用於顯式臨時表(與查詢執行中後臺使用的臨時檔案不同)的磁碟空間不計入此限制。
file_copy_method
(enum
) #指定用於複製檔案的檔案。可能的值包括 COPY
(預設)和 CLONE
(如果可用)。
此引數影響
CREATE DATABASE ... STRATEGY=FILE_COPY
ALTER DATABASE ... SET TABLESPACE ...
CLONE
使用 copy_file_range()
(Linux、FreeBSD)或 copyfile
(macOS)系統呼叫,讓核心有機會共享磁碟塊或將工作推送到某些檔案系統的較低層。
max_notify_queue_pages
(integer
) #指定用於 NOTIFY / LISTEN 佇列分配的最大頁面數。預設值為 1048576。對於 8KB 的頁面,它允許消耗高達 8GB 的磁碟空間。
max_files_per_process
(integer
) #設定每個伺服器子程序允許同時開啟的最大檔案數;在 postmaster 中已開啟的檔案不計入此限制。預設值為一千個檔案。
如果核心強制執行了安全的每個程序限制,則您無需擔心此設定。但在某些平臺(尤其是大多數 BSD 系統)上,如果許多程序都嘗試開啟大量檔案,核心將允許單個程序開啟比系統實際支援的更多的檔案。如果您遇到“檔案過多”的錯誤,請嘗試減小此設定。此引數只能在伺服器啟動時設定。
有一個名為“後臺寫入器”的獨立伺服器程序,其功能是寫入“髒”(新或已修改)共享緩衝區。當乾淨的共享緩衝區數量不足時,後臺寫入器會將一些髒緩衝區寫入檔案系統並將其標記為乾淨。這降低了處理使用者查詢的伺服器程序找不到乾淨緩衝區而不得不自行寫入髒緩衝區的可能性。然而,後臺寫入器確實會導致 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,或者 0(停用非同步 I/O 請求的發出)。預設值為 16。
較高的值將對較高延遲的儲存產生最大影響,其中查詢否則會遇到明顯的 I/O 停頓,以及對具有高 IOP 的裝置。不必要的高值可能會增加系統中所有查詢的 I/O 延遲。
在支援預讀建議的系統上,effective_io_concurrency
也控制預讀距離。
此值可以透過設定同名的表空間引數來覆蓋特定表空間中的表(請參閱 ALTER TABLESPACE)。
maintenance_io_concurrency
(integer
) #與 effective_io_concurrency
類似,但用於為許多客戶端會話執行的維護工作。
預設值為 16。此值可以透過設定同名的表空間引數來覆蓋特定表空間中的表(請參閱 ALTER TABLESPACE)。
io_max_combine_limit
(integer
) #控制組合 I/O 操作的最大 I/O 大小,並悄悄限制使用者可設定引數 io_combine_limit
。此引數只能在 postgresql.conf
檔案中或在伺服器命令列中設定。最大可能大小取決於作業系統和塊大小,但在 Unix 上通常為 1MB,在 Windows 上為 128KB。預設值為 128KB。
io_combine_limit
(integer
) #控制組合 I/O 操作的最大 I/O 大小。如果設定得高於 io_max_combine_limit
引數,則將悄悄使用較低的值,因此兩者可能都需要提高才能增加 I/O 大小。最大可能大小取決於作業系統和塊大小,但在 Unix 上通常為 1MB,在 Windows 上為 128KB。預設值為 128KB。
io_max_concurrency
(integer
) #控制一個程序可以同時執行的最大 I/O 運算元。
預設設定 -1 會根據 shared_buffers 和最大程序數(max_connections、autovacuum_worker_slots、max_worker_processes 和 max_wal_senders)來選擇一個數字,但不能超過 64。
此引數只能在伺服器啟動時設定。
io_method
(enum
) #選擇非同步 I/O 的執行方法。可能的值為
worker
(使用工作程序執行非同步 I/O)
io_uring
(使用 io_uring 執行非同步 I/O,需要使用 --with-liburing
/ -Dliburing
構建)
sync
(同步執行非同步 I/O)
預設值為 worker
。
此引數只能在伺服器啟動時設定。
io_workers
(integer
) #選擇要使用的 I/O 工作程序的數量。預設值為 3。此引數只能在 postgresql.conf
檔案中或在伺服器命令列中設定。
僅當 io_method 設定為 worker
時才有效。
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
) #設定單個實用工具命令可以啟動的最大並行工作程序數。目前,支援使用並行工作程序的並行實用工具命令包括構建 B 樹、GIN 或 BRIN 索引時的 CREATE INDEX
,以及不帶 FULL
選項的 VACUUM
。並行工作程序從 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
會降低工作程序因主程序讀取元組不夠快而阻塞的可能性,但需要主程序等待工作程序啟動後才能產生第一個元組。主程序對效能的幫助或阻礙程度取決於計劃型別、工作程序數量和查詢持續時間。
如果您在文件中看到任何不正確之處、與您對特定功能的體驗不符之處或需要進一步澄清之處,請使用 此表格 報告文件問題。