19.4. 资源消耗 #
19.4.1. 内存 #
shared_buffers(integer) #设置数据库服务器用于共享内存缓冲区的内存量。默认值通常为 128 兆字节（
128MB），但如果内核设置不支持，则可能更小（在 initdb 期间确定）。此设置必须至少为 128 千字节。不过，要获得良好性能，通常需要远高于该最小值的设置。如果指定值时没有单位，则以块为单位，即BLCKSZ字节，通常为 8kB。（BLCKSZ的非默认值会改变该最小值。）此参数只能在服务器启动时设置。如果专用数据库服务器具有 1GB 或更多内存，
shared_buffers的合理初始值是系统内存的 25%。对于某些工作负载，将shared_buffers设得更大也有效，但由于 PostgreSQL 同时依赖操作系统缓存，将超过 40% 的内存分配给shared_buffers不太可能比更小的值效果更好。将shared_buffers设得更大时，通常还需要相应增加max_wal_size，以便将大量新数据或已修改数据的写入过程分散到更长的时间内。对于内存少于 1GB 的系统，适合使用更小的内存比例，以便为操作系统留出足够空间。
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 上，这被称为“transparent huge pages”（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) #设置查询操作（如排序或 hash 表）在写入临时磁盘文件之前可使用的基础最大内存量。如果未指定单位，则以千字节为单位。默认值为 4 兆字节（
4MB）。请注意，复杂查询可能同时执行多个排序和 hash 操作，每个操作在开始向临时文件写入数据之前，通常都可以使用此值指定的内存量。此外，多个正在运行的会话也可能并发执行此类操作。因此，使用的总内存量可能是work_mem值的数倍；选择此值时必须考虑这一点。排序操作用于ORDER BY、DISTINCT和归并连接。Hash 表用于哈希连接、基于 hash 的聚合、Memoize 节点以及基于 hash 的IN子查询处理。与等效的排序操作相比，基于 hash 的操作通常对可用内存更敏感。Hash 表的内存上限由
work_mem乘以hash_mem_multiplier计算得到。因此，基于 hash 的操作可以使用超过通常的work_mem基础量的内存。hash_mem_multiplier(floating point) #用于计算基于 hash 的操作可以使用的最大内存量。最终上限由
work_mem乘以hash_mem_multiplier确定。默认值为 2.0，使基于 hash 的操作可以使用通常的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）可使用的最大内存量。如果未指定单位，则以千字节为单位。默认值为 64 兆字节（64MB）。由于一个数据库会话一次只能执行一个此类操作，而一个数据库系统通常也不会并发运行很多此类操作，因此可以安全地将该值设得远大于work_mem。更大的设置可能改善清理和恢复数据库转储的性能。注意，自动清理运行时，最多可能分配此内存量的 autovacuum_max_workers 倍，因此不要将默认值设得过高。单独设置 autovacuum_work_mem 可能有助于控制这一点。
autovacuum_work_mem(integer) #指定每个自动清理工作进程可使用的最大内存量。如果未指定单位，则以千字节为单位。默认值为 -1，表示改用 maintenance_work_mem 的值。该设置不影响其他上下文中运行的
VACUUM的行为。此参数只能在postgresql.conf文件中或服务器命令行上设置。vacuum_buffer_usage_limit(integer) #指定
VACUUM和ANALYZE命令使用的缓冲区访问策略的大小。设为0时，允许操作使用任意数量的shared_buffers缓冲区。否则，有效大小范围为128 kB至16 GB。如果指定的大小超过shared_buffers大小的 1/8，则会在不提示的情况下限制为该值。默认值为2MB。如果未指定单位，则以千字节为单位。此参数可以随时设置。在执行 VACUUM 和 ANALYZE 时，可以通过BUFFER_USAGE_LIMIT选项覆盖此设置。较大的设置可能使VACUUM和ANALYZE运行得更快，但设置过大可能会将过多其他有用页面逐出共享缓冲区。logical_decoding_work_mem(integer) #指定逻辑解码在将部分已解码的更改写入本地磁盘之前可使用的最大内存量。它限制了流式逻辑复制连接使用的内存量。默认值为 64 兆字节（
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配置的方法，临时向操作系统分配额外的共享内存；由于内存管理开销，这可能较慢。在支持huge_pages设置的操作系统上，启动时通过min_dynamic_shared_memory分配的内存会受到该设置的影响；在自动管理巨型页的操作系统上，这些内存也可能更容易受益于较大的页。默认值为0（不分配）。此参数只能在服务器启动时设置。
19.4.2. 磁盘 #
temp_file_limit(integer) #指定一个进程可用于临时文件的最大磁盘空间，例如排序和 hash 临时文件，或保留游标的存储文件。尝试超过此限制的事务将被取消。如果未指定单位，则以千字节为单位。
-1（默认值）表示没有限制。只有超级用户和具有适当SET权限的用户才能更改此设置。此设置限制单个 PostgreSQL 进程在任意时刻使用的所有临时文件的总空间。需要注意，显式临时表所用的磁盘空间不计入该上限；计入的是查询执行过程中内部使用的临时文件。
file_copy_method(enum) #指定用于复制文件的方法。可能的值包括
COPY（默认）和CLONE（如果操作系统支持）。此参数会影响：
CREATE DATABASE ... STRATEGY=FILE_COPYALTER DATABASE ... SET TABLESPACE ...
CLONE使用copy_file_range()（Linux、FreeBSD）或copyfile（macOS）系统调用，使内核有机会在某些文件系统上共享磁盘块，或将工作交由更低层处理。file_extend_method(enum) #指定在诸如
COPY这类批量操作期间扩展数据文件时所使用的方法。默认会根据操作系统选择第一个可用选项：posix_fallocate（Unix）使用标准 POSIX 接口分配磁盘空间，但某些系统缺少该接口。如果接口存在但底层文件系统不支持，本选项会静默回退到write_zeros。已知当前版本的 BTRFS 在使用该选项时会禁用压缩。在提供该函数的系统上，这是默认值。write_zeros通过写入全零数据块来扩展文件。在不提供posix_fallocate函数的系统上，这是默认值。
当数据文件扩展的块数不超过 8 个时，总是使用
write_zeros方法。max_notify_queue_pages(integer) #指定 NOTIFY / LISTEN 队列可分配页面的最大数量。默认值是 1048576。对于 8 KB 页面，这允许最多消耗 8 GB 的磁盘空间。此参数只能在服务器启动时设置。
19.4.3. 内核资源使用 #
max_files_per_process(integer) #设置每个服务器子进程允许同时打开的最大文件数量。postmaster 中已经打开的文件不计入此上限。默认值为一千个文件。
如果内核强制实施了安全的每进程上限，就不必担心此设置。但在某些平台上（尤其是大多数 BSD 系统），内核允许单个进程打开的文件数量很大，如果很多进程都尝试打开这么多文件，就会远超系统实际能够支持的总量。如果遇到“Too many open files”（打开的文件过多）错误，可尝试减小此设置。此参数只能在服务器启动时设置。
19.4.4. 计时 #
timing_clock_source(enum) #选择使用操作系统或专用 CPU 指令进行计时测量的方法。可能的值有：
auto（在受支持的 x86-64 CPU 上自动选择 TSC 时钟源，否则使用操作系统时钟）system（使用操作系统时钟进行计时测量）tsc（使用 CPU 指令进行计时，例如在 x86-64 上使用RDTSC/RDTSCP）
默认值为
auto。只有超级用户可以更改此设置。不建议在查询执行期间更改该设置，因为这可能会导致间隔计时出现明显跳变，或者产生负值。如果启用，名为 TSC 的时钟源会在测量时间间隔时使用专门的 CPU 指令；它的名字来自 x86-64 上的时间戳计数器（Time-Stamp Counter）。与读取操作系统时钟相比，这可以降低计时开销，并减少叠加在实际运行时间之上的测量误差，例如在
EXPLAIN ANALYZE中。在 x86-64 CPU 上，TSC 时钟源会在
EXPLAIN ANALYZE中使用RDTSC指令。对于需要更高精度的计时，会使用RDTSCP指令，以避免由于 CPU 指令重排序造成的不准确。较旧的 x86-64 CPU 和其他架构不支持使用 TSC 时钟源，而且在使用模拟 TSC 的系统上也不建议这样做，因为它很可能比系统时钟源更慢。为了帮助决定应使用哪种时钟源，你可以运行 pg_test_timing 工具来检查 TSC 可用性并执行计时测量。
19.4.5. 后台写入器 #
有一个独立的服务器进程，称为后台写入器，负责写出“脏”（新的或修改过的）共享缓冲区。当干净的共享缓冲区数量似乎不足时，后台写入器会将一些脏缓冲区写入文件系统，并将其标记为干净。这可以降低处理用户查询的服务器进程找不到干净缓冲区、因而不得不自行写出脏缓冲区的可能性。不过，后台写入器确实会使总体 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 负载，但也会增加服务器进程必须自行发出写操作的可能性，从而延迟交互式查询。
19.4.6. 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 停顿的高延迟存储，以及高 IOPS 设备。不必要地设得过高，可能会增加系统中所有查询的 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_min_workers(integer) #设置 I/O 工作进程的最小数量。默认值为 2。此参数只能在
postgresql.conf文件中或服务器命令行中设置。仅当 io_method 设置为
worker时才有效。io_max_workers(integer) #设置 I/O 工作进程的最大数量。默认值为 8。此参数只能在
postgresql.conf文件中或服务器命令行中设置。仅当 io_method 设置为
worker时才有效。io_worker_idle_timeout(integer) #设置完全空闲的 I/O 工作进程退出前经过的时间，从而将池大小缩减到与需求匹配。默认值为 1 分钟。此参数只能在
postgresql.conf文件中或服务器命令行中设置。仅当 io_method 设置为
worker时才有效。io_worker_launch_interval(integer) #设置启动另一个 I/O 工作进程之前的最短时间。这样可以避免为短暂的突发活动创建过多工作进程。默认值为 100ms。此参数只能在
postgresql.conf文件中或服务器命令行中设置。仅当 io_method 设置为
worker时才有效。
19.4.7. 工作进程 #
max_worker_processes(integer) #设置集簇能够支持的后台进程的最大数量。此参数只能在服务器启动时设置。默认值为 8。
运行备库时，必须将此参数设为与主库相同或更大的值。否则，备库上将不允许执行查询。
更改此值时，也应考虑调整 max_parallel_workers、autovacuum_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 倍。并行查询的更多信息参见第 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，可以降低工作进程因领导者读取元组不够快而被阻塞的可能性，但在产生第一批元组之前，领导者进程必须等待工作进程启动。领导者对性能的帮助或妨碍程度取决于计划类型、工作进程数量和查询持续时间。