shared_buffers (integer) #设置数据库服务器用于共享内存缓冲区的内存量。默认值通常为 128 MB (128MB)，但如果您的内核设置不支持（在 initdb 期间确定），则可能更小。此设置必须至少为 128 KB。但是，通常需要远高于最小值的设置以获得良好的性能。如果未指定此值的单位，则视为块，即 BLCKSZ 字节，通常为 8kB。（BLCKSZ 的非默认值将更改最小值。）此参数只能在服务器启动时设置。
如果您有一个具有 1 GB 或更多 RAM 的专用数据库服务器，那么 shared_buffers 的合理起始值为系统中内存的 25%。对于某些工作负载，更大的 shared_buffers 设置也有效，但是由于 PostgreSQL 也依赖于操作系统缓存，因此分配超过 40% 的 RAM 给 shared_buffers 优于较小数量的情况不太可能发生。 对于较大的 shared_buffers 设置，通常需要相应地增加 max_wal_size，以便在更长的时间内分摊写入大量新数据或更改数据的进程。
在 RAM 少于 1 GB 的系统上，适当的 RAM 百分比较小，因此可以为操作系统留出足够的空间。
huge_pages (enum) #控制是否为主要共享内存区域请求大页面。有效值包括 try（默认值）、on 和 off。如果将 huge_pages 设置为 try，服务器将尝试请求大页面，但如果失败，则会回退到默认值。如果使用 on，则导致大页面请求失败会阻止服务器启动。如果使用 off，则不会请求大页面。服务器变量 huge_pages_status 会指示大页面的实际状态。
目前，仅 Linux 和 Windows 支持此设置。当 huge_pages 设置为 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 的情况不同）。
large_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（8MB）。（如果 BLCKSZ 不是 8kB，默认值会按比例缩放。）可以在单独的会话中更改此设置，但只能在会话中首次使用临时表之前；随后更改该值的尝试将不会对该会话产生影响。
会话会根据 temp_buffers 给定的限制按需分配临时缓冲区。在实际不需要大量临时缓冲区的会话中设置大值，其代价仅仅是每个增量一个缓冲区描述符，即大约 64 字节 temp_buffers。但是，如果实际使用了缓冲区，则会再消耗 8192 个字节（或通常是 BLCKSZ 字节）。
max_prepared_transactions (integer) #设置可以同时处于 “prepared” 状态的事务的最大数量（请参阅 PREPARE TRANSACTION）。将此参数设置为 0（这是默认设置）会禁用事务准备功能。此参数只能在服务器启动时设置。
如果您不打算使用事务准备，应将此参数设置为 0，以防止意外创建事务准备。如果您正在使用事务准备，则可能需要使 max_prepared_transactions 至少和 max_connections 一样大，以便每个会话都可以有待处理的事务准备。
在运行备用服务器时，您必须将此参数设置为与主服务器相同或更高的值。否则，备用服务器将不允许执行查询。
work_mem (整型数) #设置在将数据写入临时磁盘文件之前，查询操作（比如排序或散列表）使用的内存基础上限。如果未指定此值单位，则视其为千字节。默认值为四兆字节 (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 基础数量的内存。
在查询操作溢出的环境中，尤其是在仅增加 work_mem 会导致内存压力（内存压力通常以间歇性内存不足错误的形式出现）的情况下，请考虑增加 hash_mem_multiplier。默认设置 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 (integer) #指定每个 autovacuum 工作器进程可使用的最大内存量。如果指定此值不带单位，则视为千字节。其默认值为 -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。如果未指定该值单位，则视为千字节。这个参数可以随时设置，也可以在传递 BUFFER_USAGE_LIMIT 选项时覆盖 VACUUM 和 ANALYZE 操作。更高的设置能让 VACUUM 和 ANALYZE 以更快的速度运行，但如果设置过大，可能会导致许多其他有用的页面从共享缓冲区中被驱逐。
logical_decoding_work_mem (integer) #在将一些已解码的更改写入本地磁盘之前，指定最大内存使用量。这将限制逻辑流复制连接所使用的内存量。默认值为 64 兆字节 (64MB)。因为每个复制连接仅使用此大小的一个缓冲区，而一个安装系统通常不会同时有许多这样的连接（由 max_wal_senders 限制），所以可以将此值设置为明显高于 work_mem 的值，以减少写入磁盘的已解码更改量。
commit_timestamp_buffers (integer) #指定用于缓存 pg_commit_ts 内容的内存大小（参见 表 65.1）。如果未指定该值单位，则视为块，即 BLCKSZ 字节，通常为 8kB。默认值为 0，它会请求 shared_buffers/512，最高 1024 块，但不会少于 16 块。此参数只能在服务器启动时设置。
multixact_member_buffers (integer) #指定用于缓存 pg_multixact/members 内容的共享内存量（参见表 65.1）。如果未指定单位，则值视为块，即 BLCKSZ 字节，通常为 8 千字节。默认值为 32。此参数只能在服务器启动时设置。
multixact_offset_buffers (integer) #指定用于缓存 pg_multixact/offsets 内容的共享内存量（参见表 65.1）。如果未指定单位，则值视为块，即 BLCKSZ 字节，通常为 8 千字节。默认值为 16。此参数只能在服务器启动时设置。
notify_buffers (integer) #指定用于缓存 pg_notify 内容的共享内存量（参见表 65.1）。如果未指定单位，则值视为块，即 BLCKSZ 字节，通常为 8 千字节。默认值为 16。此参数只能在服务器启动时设置。
serializable_buffers (integer) #指定用于缓存 pg_serial 内容的共享内存量（参见表 65.1）。如果未指定单位，则值视为块，即 BLCKSZ 字节，通常为 8 千字节。默认值为 32。此参数只能在服务器启动时设置。
subtransaction_buffers (integer) #指定用于缓存 pg_subtrans 内容的共享内存量（参见表 65.1）。如果未指定单位，则值视为块，即 BLCKSZ 字节，通常为 8 千字节。默认值为 0，它请求 shared_buffers/512，最多 1024 个块，最少 16 个块。此参数只能在服务器启动时设置。
transaction_buffers (integer) #指定要用于缓存 pg_xact 内容的共享内存量（请参阅 表 65.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 进程使用所有临时文件所用的总空间大小。需要注意的是，显式临时表使用的磁盘空间不同于在查询执行过程中后台使用的临时文件，不 计入此限制。
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_cost_delay 变量设置为非零值。
vacuum_cost_delay (浮点数) #当超出成本限制时，进程休眠的时间量。如果此值未指定单位，则以毫秒为单位。默认值为零，将禁用基于成本的真空延迟功能。正值启用基于成本的真空整理。
在使用基于成本的 vacuum 整理时，vacuum_cost_delay 的合适数值通常会比较小，可能不到 1 毫秒。虽然 vacuum_cost_delay 可设为千分之几毫秒的值，但较旧平台可能无法精确测量这样的延迟。在这样的平台上，要使 VACUUM 的节流资源消耗量超出 1ms 时获得的消耗量，就需要更改其他真空成本参数。尽管如此，你应该让 vacuum_cost_delay 尽可能小，以确保你的平台能够持续测量；延迟时间较长无益。
vacuum_cost_page_hit (整数) #为共享缓冲区缓存中找到的缓冲区进行 Vacuum 整理的估计成本。它表示锁定缓冲池、查找共享哈希表和扫描页面内容的成本。默认值为 1。
vacuum_cost_page_miss (整数) #为必须从磁盘读取的缓冲区进行 Vacuum 整理的估计成本。它表示锁定缓冲池、查找共享哈希表、从磁盘读入所需块并扫描其内容所需的努力。默认值为 2。
vacuum_cost_page_dirty (整数) #当 Vacuum 整理修改以前是干净的块时收取的估计成本。它表示将脏块再次刷新到磁盘所需的额外 I/O。默认值为 20。
vacuum_cost_limit (整数) #这是累积成本，将导致真空过程休眠 vacuum_cost_delay。默认值为 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 (浮点数) #每次循环中写入的已修改缓冲区的数量基于服务器进程在最近的循环中所需的新缓冲区的数量。将最近所需的平均值乘以 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，或为零以禁用异步 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 (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 树索引时使用的 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 可降低工作程序因领导进程读取元组不够快而被阻塞的可能性，但要求领导进程在开始生成元组之前等待工作程序进程启动。领导进程有助于或阻碍性能的程度取决于计划类型、工作程序数量和查询持续时间。