shared_buffers (integer) #设置数据库服务器用于共享内存缓冲区的内存量。默认值通常为 128 兆字节 (128MB)，但如果您的内核设置不支持（如在 initdb 期间确定），则可能会更少。此设置必须至少为 128 千字节。但是，通常需要明显高于最小值的设置才能获得良好的性能。如果此值未指定单位，则将其视为块，即 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) #控制是否为主要共享内存区域请求大页面。有效值为 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（英特尔和 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 给出的限制。在实际上不需要太多临时缓冲区的会话中设置大值的成本仅是一个缓冲区描述符，或大约 64 字节，每次增加 temp_buffers。但是，如果实际使用缓冲区，则会为其消耗额外的 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 基准量的内存。
在查询操作频繁发生溢出的环境中，请考虑增加 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_max_workers 倍的内存，因此请注意不要将默认值设置得太高。可以通过单独设置 autovacuum_work_mem 来控制这一点。
autovacuum_work_mem (整数) #指定每个自动清理工作进程可以使用的最大内存量。如果此值在指定时没有单位，则以千字节为单位。默认值为 -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) #在共享缓冲区缓存中找到的 vacuum 缓冲区的估计成本。它表示锁定缓冲池、查找共享哈希表和扫描页面内容的成本。默认值为 1。
vacuum_cost_page_miss (integer) #必须从磁盘读取的 vacuum 缓冲区的估计成本。这表示锁定缓冲池、查找共享哈希表、从磁盘读取所需块并扫描其内容的成本。默认值为 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 (浮点数) #每一轮写入的脏缓冲区数量基于服务器进程在最近几轮中需要的新缓冲区数量。最近需要的平均值乘以 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 函数，某些操作系统缺少此函数。如果该函数不存在，则将此参数设置为 0 以外的任何值都会导致错误。在某些操作系统（例如，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 (boolean) #允许领导进程在 Gather 和 Gather Merge 节点下执行查询计划，而不是等待工作进程。默认值为 on。将此值设置为 off 可以降低工作进程因领导进程读取元组速度不够快而被阻塞的可能性，但需要领导进程等待工作进程启动后才能生成第一个元组。领导进程在多大程度上能够帮助或阻碍性能取决于计划类型、工作进程的数量和查询持续时间。
如果您在文档中发现任何不正确、与您特定功能体验不符或需要进一步澄清的地方，请使用此表单报告文档问题。