shared_buffers (integer) #设置数据库服务器将使用的共享内存缓冲区量。默认通常是 128 兆字节（128MB），但是如果你的内核设置不支持（在initdb时决定），那么可以会更少。 这个设置必须至少为 128 千字节。不过为了更好的性能，通常会使用明显高于最小值的设置。 如果指定值时没有单位，则以块为单位，即BLCKSZ字节，通常为8kB.(BLCKSZ 的非默认值改变最小值。) 此参数只能在服务器启动时设置。
如果有一个专用的 1GB 或更多内存的数据库服务器，一个合理的shared_buffers开始值是系统内存的 25%。即使更大的shared_buffers有效，也会造成一些工作负载， 但因为PostgreSQL同样依赖操作系统的高速缓冲区，将shared_buffers设置为超过 40% 的RAM不太可能比一个小点值工作得更好。为了能把对写大量新的或改变的数据的处理分布在一个较长的时间段内，shared_buffers更大的设置通常要求对max_wal_size也做相应增加。
如果系统内存小于 1GB，一个较小的 RAM 百分数是合适的，这样可以为操作系统留下足够的空间。
huge_pages (enum) #控制是否为主共享内存区域请求巨型页。有效值是try（默认）、on以及off。该参数只能在服务器启动时设置。如果huge_pages被设置为try，则服务器将尝试请求巨型页，但是如果失败会退回到默认的方式。如果为on，请求巨型页失败将使得服务器无法启动。如果为off，则不会请求巨型页。
当前，只有Linux和Windows上支持这个设置。在其他系统上这个参数被设置为try时，它会被忽略。 在Linux中，它只在shared_memory_type设置为mmap（默认）的时候被支持。
巨型页面的使用会导致更小的页面表以及花费在内存管理上的 CPU 时间更少，从而提高性能。更多有关Linux上使用巨型页面的细节请见Section 18.4.5。
巨型页在Windows上被称为大页面。 要使用大页面，需要为运行PostgreSQL的Windows用户账号分配“在内存中锁定页面”的用户权限。 可以使用Windows的组策略工具（gpedit.msc）来分配用户权限“在内存中锁定页面”。 为了在命令窗口以单进程（而不是Windows服务）的方式启动数据库服务器，命令窗口必须以管理员身份运行或者禁用用户访问控制（UAC）。 当UAC被启用时，普通的命令窗口会在启动时收回用户权限“在内存中锁定页面”。
注意这种设置仅影响主共享内存区域。Linux、FreeBSD以及Illumos之类的操作系统也能为普通内存分配自动使用巨型页（也被称为“超级”页或者“大”页面），而不需要来自PostgreSQL的显式请求。在Linux上，这被称为“transparent huge pages”（THP，透明巨型页）。已知这种特性对某些Linux版本上的某些用户会导致PostgreSQL的性能退化，因此当前并不鼓励使用它（与huge_pages的显式使用不同）。
huge_page_size (integer) #控制巨型页的大小，当他们通过huge_pages时。 默认为零 (0)。 当设置为0时，将使用系统默认的巨型页大小。 这个参数只能在服务器启动时设置。
一些现代64位服务器体系结构上常用的有效页尺寸包括： 2MB 和 1GB (Intel and AMD), 16MB 和 16GB (IBM POWER), 还有 64kB, 2MB,32MB 和 1GB (ARM). 关于使用和支持的更多信息，参见Section 18.4.5。
非默认设置当前仅在Linux上支持。
temp_buffers (integer) #为每个数据库会话设置用于临时缓冲区的最大内存。这些缓冲区是仅用于访问临时表的会话本地缓冲区。 如果指定值时没有单位，则以块为单位，即BLCKSZ字节，通常为8kB。 默认为 8 兆字节（8MB）。（如果BLCKSZ不是 8 kB，则默认值按比例缩放。） 这个设置可以在独立的会话内部被改变，但是只有在会话第一次使用临时表之前才能改变； 在会话中随后企图改变该值是无效的。
一个会话将按照temp_buffers给出的限制根据需要分配临时缓冲区。如果在一个并不需要大量临时缓冲区的会话里设置一个大的数值， 其开销只是一个缓冲区描述符，或者说temp_buffers每增加一则增加大概 64 字节。不过，如果一个缓冲区被实际使用，那么它就会额外消耗 8192 字节（或者BLCKSZ字节）。
max_prepared_transactions (integer) #设置可以同时处于“prepared”状态的事务的最大数目（见PREPARE TRANSACTION）。把这个参数设置 为零（这是默认设置）将禁用预备事务特性。这个参数只能在服务器启动时设置。
如果你不打算使用预备事务，可以把这个参数设置为零来防止意外创建预备事务。如果你正在使用预备事务，你将希望把max_prepared_transactions至少设置为max_connections一样大，因此每一个会话可以有一个预备事务待处理。
当运行一个备库时，你必须设置这个参数等于或大于主库上的参数。 否则，备库上可能无法允许查询。
work_mem (integer) #设置查询操作（如排序或哈希表）在写入临时磁盘文件之前可使用的基本最大内存量。 如果未指定单位，则将其视为千字节。默认值为四兆字节（4MB）。 请注意，复杂查询可能同时执行多个排序和哈希操作， 每个操作通常允许在开始将数据写入临时文件之前使用此值指定的内存量。 此外，可能有多个正在运行的会话同时执行此类操作。 因此，使用的总内存量可能是work_mem值的多倍； 在选择值时必须牢记这一事实。排序操作用于ORDER BY、DISTINCT和合并连接。 哈希表用于哈希连接、基于哈希的聚合、记忆节点和IN子查询的基于哈希的处理。
基于哈希的操作通常比等效的基于排序的操作更加敏感于内存可用性。 哈希表的可用内存通过将work_mem乘以 hash_mem_multiplier来计算。默认值为 1.0，这使得基于哈希的操作受到与基于排序的操作相同的简单work_mem最大值的限制。
hash_mem_multiplier (floating point) #用于计算哈希操作可以使用的最大内存量。最终限制由将work_mem乘以hash_mem_multiplier确定。 默认值为1.0，这使得基于哈希的操作与基于排序的操作受到相同的work_mem简单最大值的限制。
考虑在查询操作频繁溢出的环境中增加hash_mem_multiplier， 特别是当简单增加work_mem导致内存压力时（内存压力通常表现为间歇性的内存不足错误）。 将设置调到1.5或2.0通常在混合工作负载中有效。在已将work_mem增加到40MB或更高的环境中， 可以考虑将设置调高至2.0-8.0或更高。
maintenance_work_mem (integer) #指定维护操作（如 VACUUM、CREATE INDEX 和 ALTER TABLE ADD FOREIGN KEY）可使用的最大内存量。 如果指定值时未带单位，则按千字节解释。默认值为 64 兆字节（64MB）。 由于数据库会话一次只能执行一个这样的操作，而一个安装通常也不会有很多此类操作并发运行， 因此把该值设置得明显大于 work_mem 通常是安全的。更大的设置可能改善清理和恢复数据库转储的性能。
注意当自动清理运行时，可能会分配最多达这个内存的autovacuum_max_workers倍，因此要小心不要把该默认值设置得太高。 通过独立地设置autovacuum_work_mem可能会对控制这种情况 有所帮助。
autovacuum_work_mem (integer) #指定每个自动清理工作者进程能使用的最大内存量。 如果指定值时没有单位，则以千字节为单位。 其默认值为 -1，表示转而使用 maintenance_work_mem的值。 当运行在其他上下文环境中时，这个设置对VACUUM的行为没有影响。 这个参数只能在postgresql.conf中或者服务器命令行上设置。
logical_decoding_work_mem (integer) #指定逻辑解码要使用的最大内存量，在将某些解码的更改写入本地磁盘之前。 这将限制逻辑流复制连接使用的内存量。它默认为 64 兆字节（64MB）。 由于每个复制连接仅使用此大小的单个缓冲区，并且安装通常不会同时具有多个此类连接（受 max_wal_senders 的限制），因此将此值设置得明显高于 work_mem是安全的，从而减少写入磁盘的解码更改数量。
commit_timestamp_buffers (integer) #指定用于缓存pg_commit_ts内容的内存量 （参见Table 68.1）。如果未指定单位，则视为块， 即BLCKSZ字节，通常为 8KB。默认值为0， 这会请求shared_buffers/512，最多 1024 个块、最少 16 个块。 此参数只能在服务器启动时设置。
multixact_member_buffers (integer) #指定用于缓存pg_multixact/members内容的共享内存量 （参见Table 68.1）。如果未指定单位，则视为块， 即BLCKSZ字节，通常为 8KB。默认值为 32。此参数只能在服务器启动时设置。
multixact_offset_buffers (integer) #指定用于缓存pg_multixact/offsets内容的共享内存量 （参见Table 68.1）。如果未指定单位，则视为块， 即BLCKSZ字节，通常为 8KB。默认值为 16。此参数只能在服务器启动时设置。
notify_buffers (integer) #指定用于缓存pg_notify内容的共享内存量 （参见Table 68.1）。如果未指定单位，则视为块， 即BLCKSZ字节，通常为 8KB。默认值为 16。此参数只能在服务器启动时设置。
serializable_buffers (integer) #指定用于缓存pg_serial内容的共享内存量 （参见Table 68.1）。如果未指定单位，则视为块， 即BLCKSZ字节，通常为 8KB。默认值为 32。此参数只能在服务器启动时设置。
subtransaction_buffers (integer) #指定用于缓存pg_subtrans内容的共享内存量 （参见Table 68.1）。如果未指定单位，则视为块， 即BLCKSZ字节，通常为 8KB。默认值为0， 这会请求shared_buffers/512，最多 1024 个块、最少 16 个块。 此参数只能在服务器启动时设置。
transaction_buffers (integer) #指定用于缓存pg_xact内容的共享内存量 （参见Table 68.1）。如果未指定单位，则视为块， 即BLCKSZ字节，通常为 8KB。默认值为0， 这会请求shared_buffers/512，最多 1024 个块、最少 16 个块。 此参数只能在服务器启动时设置。
max_stack_depth (integer) #指定服务器执行栈的最大安全深度。此参数的理想设置是由内核强制执行的实际栈大小限制 （如由ulimit -s或本地等效设置），减去大约一兆字节的安全边界。 需要安全边界是因为服务器中并非每个例程都检查栈深度，而只在关键的潜在递归例程中检查。 如果未指定单位，则将其视为千字节。默认设置为两兆字节（2MB）， 这是保守且不太可能引起崩溃的小值。但是，这可能太小，无法执行复杂函数。 只有超级用户能更改这个设置。
把max_stack_depth参数设置得高于实际的内核限制将意味着一个失控的递归函数可能会导致一个独立的后端进程崩溃。 在PostgreSQL能够检测内核限制的平台上， 服务器将不允许把这个参数设置为一个不安全的值。不过，并非所有平台都能提供该信息，所以我们还是建议你在选择值时要小心。
shared_memory_type (enum) #指定服务器应用于主共享内存区域的共享内存实现，包括 PostgreSQL 的共享缓冲区和其他共享数据。 可能的值为 mmap（对使用 mmap 分配的匿名共享内存）、sysv（通过 shmget 分配的 System V 共享内存）和 windows（Windows 共享内存）。 并非在所有平台上都支持全部值；第一个受支持的选项是该平台的默认选项。 sysv 选项不是任何平台的默认选项，通常不建议使用，因为它通常需要非默认的内核设置来允许大量的地址分配（参见 Section 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（默认值）表示没有限制。 只有超级用户能更改这个设置。
这个设置约束着一个给定PostgreSQL进程在任何瞬间所使用的所有临时文件的总空间。应该注意的是，与在查询执行中在幕后使用的临时文件相反，显式临时表所用的磁盘空间不被这个设置所限制。
max_files_per_process (integer) #设置每个服务器子进程允许同时打开的最大文件数。默认值是一千个文件。
如果内核强制实施了安全的每进程上限，你通常不必担心这个设置。但在某些平台上 （尤其是大多数 BSD 系统），如果许多进程都尝试打开大量文件，内核可能允许单个进程打开的文件数 远超系统在整体上真正能够支持的数量。如果你看到“打开的文件过多”之类的失败， 可以尝试减小这个设置。这个参数只能在服务器启动时设置。
在VACUUM和ANALYZE命令的执行过程中，系统维持着一个内部计数器来跟踪各种被执行的I/O操作的估算开销。当累计的代价达到一个限制（由vacuum_cost_limit指定），执行这些操作的进程将按照vacuum_cost_delay所指定的休眠一小段时间。然后它将重置计数器并继续执行。
这个特性的出发点是允许管理员降低这些命令对并发的数据库活动产生的I/O影响。在很多情况下，VACUUM和ANALYZE等维护命令能否快速完成并不重要，而非常重要的是这些命令不会对系统执行其他数据库操作的能力产生显著的影响。基于代价的清理延迟提供了一种方式让管理员能够保证这一点。
对于手动发出的VACUUM命令，该特性默认被禁用。要启用它，只要把vacuum_cost_delay变量设为一个非零值。
vacuum_cost_delay (floating point) #当超出开销限制时进程将要休眠的时间量。如果指定值时没有单位，则以毫秒为单位。 其默认值为0，这将禁用基于代价的清理延迟特性。正值将启用基于代价的清理。
在使用基于代价的清理时，vacuum_cost_delay的合适值通常很小，也许是小于1毫秒。 虽然vacuum_cost_delay可以被设置为毫秒级别的值，但是在较老的平台上可能无法准确地测量这种延迟。 在这样的平台上，增加 VACUUM的节流资源消耗在1ms以上，需要改变其他的清理开销参数。 尽管如此，你应该保持 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) #将导致清理进程休眠的累计代价。默认值为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) #只要后台写入的数据超过这个数量，尝试强制 OS 把这些写发送到底层存储上。这样做将限制内核页缓存中脏数据的量，降低了在检查点末尾发出一个 fsync 时或者 OS 在后台大批量写回数据时卡住的可能性。 那常常会导致大幅度压缩的事务延迟，但是也有一些情况（特别是负载超过shared_buffers但小于 OS 页面高速缓存）的性能会降低。这种设置可能会在某些平台上没有效果。 如果指定值时没有单位，则以块为单位，即为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。
较高的值对高延迟存储和高 IOPS 设备影响最大，否则查询会经历明显的 I/O 停顿。不必要地设置过高，可能会增加系统中所有查询的 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。该参数只能在服务器启动时设置。 如果该值未指定单位，则按块计算，也就是 BLCKSZ 字节，通常为 8kB。 最大可能值取决于操作系统和块大小，但在 Unix 上通常为 1MB，在 Windows 上通常为 128kB。 默认值是 128kB。
io_combine_limit (integer) #控制合并 I/O 操作时允许的最大 I/O 大小。如果设置值高于 io_max_combine_limit 参数，则会静默使用较低的那个值， 因此如果要增大 I/O 大小，可能需要同时提高这两个参数。 如果该值未指定单位，则按块计算，也就是 BLCKSZ 字节，通常为 8kB。 最大可能值取决于操作系统和块大小，但在 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 个工作者的并行查询使用的 CPU 时间、内存、I/O 带宽可能是不使用工作者时的 5 倍之多。
并行查询的更多信息请见Chapter 15。
max_parallel_maintenance_workers (integer) #设置单一工具性命令能够启动的并行工作者的最大数目。 当前，支持使用并行工作者的工具性命令是CREATE INDEX，并且只有在构建B-树索引时才能并行，并且 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将不会产生效果，因为并行工作者进程都是从max_worker_processes所建立的工作者进程池中取出来的。
parallel_leader_participation (boolean) #允许 leader 进程在Gather和Gather Merge节点下参与执行查询计划，而不是仅仅等待 worker 进程。 默认值是on。 将其设置为off可以降低 worker 因 leader 读取元组速度不够快而被阻塞的可能性， 但在生成第一条元组之前，leader 进程将需要等待 worker 进程启动。 leader 对性能的帮助或拖累程度取决于计划类型、worker 数量以及查询持续时间。
如果您发现文档中有不正确的内容、与您使用特定功能的经验不符或需要进一步说明，请使用此表单来报告文档问题。