shared_buffers (integer) #设置数据库服务器用于共享内存缓冲区的内存量。默认值通常为 128 兆字节 (128MB)，但如果您的内核设置不支持它（在 initdb 期间确定），则可能会更小。此设置必须至少为 128 千字节。但是，通常需要比最小值高得多的设置才能获得良好的性能。如果此值未指定单位，则将其视为块，即 BLCKSZ 字节，通常为 8kB。（BLCKSZ 的非默认值会更改最小值。）此参数只能在服务器启动时设置。
如果您有一个具有 1GB 或更多 RAM 的专用数据库服务器，则 shared_buffers 的合理起始值为系统内存的 25%。某些工作负载即使对 shared_buffers 进行更大的设置也更有效，但由于 PostgreSQL 也依赖于操作系统缓存，因此分配超过 RAM 的 40% 给 shared_buffers 的效果不太可能优于较小的数量。较大的 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 等操作系统也可以自动对普通内存分配使用巨型页面（也称为“超级”页面或“大”页面），而无需 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。默认值为 8 兆字节 (8MB)。（如果 BLCKSZ 不是 8kB，则默认值会按比例缩放。）此设置可以在各个会话中更改，但只能在会话中第一次使用临时表之前更改；后续尝试更改该值将对该会话没有影响。
会话将根据需要分配临时缓冲区，直到达到 temp_buffers 给出的限制。在实际上不需要许多临时缓冲区的会话中设置较大的值的成本仅为每个 temp_buffers 增量的一个缓冲区描述符，或大约 64 字节。但是，如果实际使用了缓冲区，则将为其消耗另外 8192 字节（或通常为 BLCKSZ 字节）。
max_prepared_transactions (integer) #设置可以同时处于“已准备”状态的事务的最大数量（请参阅PREPARE TRANSACTION）。将此参数设置为零（默认值）将禁用已准备事务功能。此参数只能在服务器启动时设置。
如果您不打算使用已准备事务，则应将此参数设置为零以防止意外创建已准备事务。如果您正在使用已准备事务，则可能希望 max_prepared_transactions 至少与 max_connections 一样大，以便每个会话都可以有一个已准备的事务挂起。
运行备用服务器时，必须将此参数设置为与主服务器相同或更高的值。否则，备用服务器将不允许查询。
work_mem (integer) #设置查询操作（例如排序或哈希表）在写入临时磁盘文件之前使用的基本最大内存量。如果此值未指定单位，则将其视为千字节。默认值为 4 兆字节 (4MB)。请注意，复杂的查询可能同时执行多个排序和哈希操作，每个操作通常都允许使用此值指定的内存量，然后才开始将数据写入临时文件。此外，多个正在运行的会话可以同时执行此类操作。因此，使用的总内存可能是 work_mem 值的许多倍；在选择值时，有必要牢记这一点。排序操作用于 ORDER BY、DISTINCT 和合并连接。哈希表用于哈希连接、基于哈希的聚合、记忆节点和基于哈希的 IN 子查询处理。
基于哈希的操作通常比等效的基于排序的操作对内存可用性更敏感。哈希表的内存限制通过将work_mem乘以hash_mem_multiplier来计算。这使得基于哈希的操作可以使用超过通常work_mem基本量的内存。
hash_mem_multiplier (浮点数) #用于计算基于哈希的操作可以使用的最大内存量。最终限制由work_mem乘以hash_mem_multiplier决定。默认值为 2.0，这使得基于哈希的操作使用通常work_mem基本量的两倍。
在查询操作经常发生溢出（spilling）的环境中，考虑增加hash_mem_multiplier，尤其是在简单地增加work_mem会导致内存压力（内存压力通常表现为间歇性的内存不足错误）的情况下。默认设置 2.0 通常在混合工作负载中有效。在work_mem已经增加到 40MB 或更大的环境中，2.0 - 8.0 或更高的设置可能有效。
maintenance_work_mem (整数) #指定维护操作（例如VACUUM、CREATE INDEX和ALTER TABLE ADD FOREIGN KEY）使用的最大内存量。如果此值未指定单位，则将其视为千字节。默认为 64 兆字节（64MB）。由于数据库会话一次只能执行其中一项操作，并且安装通常没有太多此类操作并发运行，因此将此值设置为显著大于work_mem是安全的。更大的设置可能会提高真空操作和恢复数据库转储的性能。
请注意，当 autovacuum 运行时，最多可以分配autovacuum_max_workers倍的此内存，因此请注意不要将默认值设置得太高。可以通过单独设置autovacuum_work_mem来控制这一点。
autovacuum_work_mem (整数) #指定每个 autovacuum 工作进程使用的最大内存量。如果此值未指定单位，则将其视为千字节。默认为 -1，表示应使用maintenance_work_mem的值。此设置对在其他上下文中运行的VACUUM的行为没有影响。此参数只能在postgresql.conf文件中或服务器命令行上设置。
vacuum_buffer_usage_limit (整数) #指定VACUUM和ANALYZE命令使用的缓冲区访问策略的大小。设置为0将允许操作使用任意数量的shared_buffers。否则，有效大小范围为128 kB到16 GB。如果指定的大小超过shared_buffers大小的 1/8，则大小将静默限制为该值。默认值为2MB。如果此值未指定单位，则将其视为千字节。此参数可以在任何时候设置。它可以在传递BUFFER_USAGE_LIMIT选项时被VACUUM和ANALYZE覆盖。更高的设置可以使VACUUM和ANALYZE运行得更快，但设置过大可能会导致太多其他有用的页面从共享缓冲区中被逐出。
logical_decoding_work_mem (整数) #指定逻辑解码在将一些解码后的更改写入本地磁盘之前可以使用的最大内存量。这限制了逻辑流式复制连接使用的内存量。默认为 64 兆字节（64MB）。由于每个复制连接只使用一个此大小的缓冲区，并且安装通常没有太多此类连接并发（受max_wal_senders限制），因此将此值设置为显著高于work_mem是安全的，从而减少写入磁盘的解码更改数量。
commit_timestamp_buffers (整数) #指定用于缓存pg_commit_ts内容的内存量（参见表 65.1）。如果此值未指定单位，则将其视为块，即BLCKSZ字节，通常为 8kB。默认值为0，它请求shared_buffers/512 最多 1024 个块，但不少于 16 个块。此参数只能在服务器启动时设置。
multixact_member_buffers (整数) #指定用于缓存pg_multixact/members内容的共享内存量（参见表 65.1）。如果此值未指定单位，则将其视为块，即BLCKSZ字节，通常为 8kB。默认值为32。此参数只能在服务器启动时设置。
multixact_offset_buffers (整数) #指定用于缓存pg_multixact/offsets内容的共享内存量（参见表 65.1）。如果此值未指定单位，则将其视为块，即BLCKSZ字节，通常为 8kB。默认值为16。此参数只能在服务器启动时设置。
notify_buffers (整数) #指定用于缓存pg_notify内容的共享内存量（参见表 65.1）。如果此值未指定单位，则将其视为块，即BLCKSZ字节，通常为 8kB。默认值为16。此参数只能在服务器启动时设置。
serializable_buffers (整数) #指定用于缓存pg_serial内容的共享内存量（参见表 65.1）。如果此值未指定单位，则将其视为块，即BLCKSZ字节，通常为 8kB。默认值为32。此参数只能在服务器启动时设置。
subtransaction_buffers (整数) #指定用于缓存pg_subtrans内容的共享内存量（参见表 65.1）。如果此值未指定单位，则将其视为块，即BLCKSZ字节，通常为 8kB。默认值为0，它请求shared_buffers/512 最多 1024 个块，但不少于 16 个块。此参数只能在服务器启动时设置。
transaction_buffers (整数) #指定用于缓存pg_xact内容的共享内存量（参见表 65.1）。如果此值未指定单位，则将其视为块，即BLCKSZ字节，通常为 8kB。默认值为0，它请求shared_buffers/512 最多 1024 个块，但不少于 16 个块。此参数只能在服务器启动时设置。
max_stack_depth (整数) #指定服务器执行堆栈的最大安全深度。此参数的理想设置是内核强制执行的实际堆栈大小限制（由ulimit -s或本地等效项设置），减去大约 1 兆字节的安全裕度。需要安全裕度是因为服务器中并非每个例程都会检查堆栈深度，而仅在关键的潜在递归例程中检查。如果此值未指定单位，则将其视为千字节。默认设置为 2 兆字节（2MB），这比较保守，不太可能导致崩溃。但是，它可能太小，无法允许执行复杂的函数。只有超级用户和具有相应SET权限的用户可以更改此设置。
将max_stack_depth设置为高于实际内核限制将意味着失控的递归函数可能会导致单个后端进程崩溃。在PostgreSQL可以确定内核限制的平台上，服务器将不允许将此变量设置为不安全的值。但是，并非所有平台都提供此信息，因此在选择值时建议谨慎。
shared_memory_type (枚举) #指定服务器应为保存 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 进程在任何时刻使用的所有临时文件使用的总空间。需要注意的是，用于显式临时表的磁盘空间（与查询执行过程中后台使用的临时文件相反）不会计入此限制。
max_notify_queue_pages (integer) #指定 NOTIFY / LISTEN 队列分配的页面最大数量。默认值为 1048576。对于 8 KB 页面，它允许消耗高达 8 GB 的磁盘空间。
max_files_per_process (integer) #设置允许每个服务器子进程同时打开的文件的最大数量。默认值为一千个文件。如果内核正在强制执行安全的每个进程限制，则无需担心此设置。但在某些平台（尤其是一些 BSD 系统）上，如果许多进程都尝试打开很多文件，内核将允许单个进程打开的文件数量远超过系统实际支持的数量。如果您发现出现 “打开的文件过多” 错误，请尝试减少此设置。此参数只能在服务器启动时设置。
在执行 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) #Vacuum 修改先前干净的块时收取的估计成本。它表示将脏块再次刷新到磁盘所需的额外 I/O。默认值为 20。
vacuum_cost_limit (integer) #这是将导致 Vacuum 进程休眠 vacuum_cost_delay 的累积成本。默认值为 200。
某些操作持有关键锁，因此应尽快完成。在此类操作期间不会发生基于成本的 Vacuum 延迟。因此，成本可能会累积远高于指定的限制。为了避免在这些情况下出现无用的长时间延迟，实际延迟计算为 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 (整数) #当后台写入器写入的数据量超过此值时，尝试强制操作系统将这些写入发出到底层存储。这样做将限制内核页面缓存中脏数据的数量，减少在检查点结束时发出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 (整数) #当单个后端写入的数据量超过此值时，尝试强制操作系统将这些写入发出到底层存储。这样做将限制内核页面缓存中脏数据的数量，减少在检查点结束时发出fsync或操作系统在后台批量写入数据时发生停顿的可能性。通常这会导致事务延迟大大降低，但也有一些情况，特别是当工作负载大于shared_buffers但小于操作系统的页面缓存时，性能可能会下降。此设置在某些平台上可能无效。如果此值指定时没有单位，则将其视为块，即BLCKSZ字节，通常为 8kB。有效范围在0（禁用强制回写）和2MB之间。默认值为0，即不强制回写。（如果BLCKSZ不是 8kB，则最大值将按比例缩放。）
effective_io_concurrency (整数) #设置PostgreSQL期望可以同时执行的并发磁盘 I/O 操作的数量。提高此值将增加任何单个PostgreSQL会话尝试并行启动的 I/O 操作的数量。允许的范围是 1 到 1000，或 0 以禁用异步 I/O 请求的发起。目前，此设置仅影响位图堆扫描。
对于磁驱动器，此设置的一个好的起点是构成用于数据库的 RAID 0 条带或 RAID 1 镜像的独立驱动器的数量。（对于 RAID 5，不应计算奇偶校验驱动器。）但是，如果数据库经常忙于并发会话中发出的多个查询，则较低的值可能足以使磁盘阵列保持繁忙。高于使磁盘保持繁忙所需的数值只会导致额外的 CPU 开销。SSD 和其他基于内存的存储通常可以处理许多并发请求，因此最佳值可能在数百个左右。
异步 I/O 依赖于有效的posix_fadvise函数，而某些操作系统缺少此函数。如果该函数不存在，则将此参数设置为除零以外的任何值都将导致错误。在某些操作系统（例如 Solaris）上，该函数存在，但实际上什么也不做。
在受支持的系统上默认为 1，否则为 0。可以通过设置表空间中相同名称的表空间参数来覆盖此值（请参阅ALTER TABLESPACE）。
maintenance_io_concurrency (整数) #类似于effective_io_concurrency，但用于代表许多客户端会话执行的维护工作。
在受支持的系统上默认为 10，否则为 0。可以通过设置表空间中相同名称的表空间参数来覆盖此值（请参阅ALTER TABLESPACE）。
io_combine_limit (整数) #控制组合 I/O 操作中最大的 I/O 大小。默认为 128kB。
max_worker_processes (整数) #设置集群可以支持的最大后台进程数。此参数只能在服务器启动时设置。默认为 8。
运行备用服务器时，必须将此参数设置为与主服务器相同或更高的值。否则，备用服务器将不允许查询。
更改此值时，请考虑同时调整max_parallel_workers、max_parallel_maintenance_workers和max_parallel_workers_per_gather。
max_parallel_workers_per_gather (整数) #设置单个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 (整数) #设置单个实用程序命令可以启动的最大并行工作程序数量。目前，支持使用并行工作程序的并行实用程序命令只有在构建 B 树索引时才使用CREATE INDEX，以及不带FULL选项的VACUUM。并行工作程序取自max_worker_processes建立的进程池，受max_parallel_workers限制。请注意，在运行时可能无法实际获得请求的工作程序数量。如果发生这种情况，实用程序操作将使用比预期更少的工作程序运行。默认值为 2。将此值设置为 0 将禁用实用程序命令使用并行工作程序。
请注意，并行实用程序命令消耗的内存不应显着多于等效的非并行操作。此策略与并行查询的策略不同，在并行查询中，资源限制通常适用于每个工作程序进程。并行实用程序命令将资源限制maintenance_work_mem视为应用于整个实用程序命令的限制，而不管并行工作程序进程的数量如何。但是，并行实用程序命令仍然可能消耗大量 CPU 资源和 I/O 带宽。
max_parallel_workers (整数) #设置集群可以支持的最大并行操作工作程序数量。默认值为 8。增加或减少此值时，请考虑同时调整max_parallel_maintenance_workers和max_parallel_workers_per_gather。此外，请注意，此值设置为高于max_worker_processes的值将无效，因为并行工作程序取自该设置建立的工作程序进程池。
parallel_leader_participation (布尔值) #允许主进程在Gather和Gather Merge节点下执行查询计划，而不是等待工作进程。默认值为on。将此值设置为off可以降低工作进程因主进程读取元组速度不够快而被阻塞的可能性，但要求主进程等待工作进程启动才能生成第一个元组。主进程可以帮助或阻碍性能的程度取决于计划类型、工作进程数量和查询持续时间。
如果您在文档中发现任何不正确的内容，与您对特定功能的体验不符，或者需要进一步澄清，请使用此表单 报告文档问题。