2025年9月25日: PostgreSQL 18 发布!
支持版本:当前 (18) / 17 / 16 / 15 / 14 / 13
开发版本:devel
不支持的版本:12 / 11 / 10 / 9.6 / 9.5 / 9.4 / 9.3 / 9.2 / 9.1 / 9.0 / 8.4 / 8.3 / 8.2 / 8.1

19.4. 资源消耗 #

19.4.1. 内存 #

shared_buffers (integer) #

设置数据库服务器用于共享内存缓冲区的内存量。默认值通常是 128MB,但在 initdb 过程中,如果内核设置不支持,则可能更少。此设置必须至少为 128KB。然而,为了获得良好的性能,通常需要远大于最小值的设置。如果此值未指定单位,则假定为块,即 BLCKSZ 字节,通常为 8KB。(BLCKSZ 的非默认值会改变最小值。)此参数只能在服务器启动时设置。

如果您有 1GB 或更多 RAM 的专用数据库服务器,shared_buffers 的合理起始值是系统内存的 25%。对于某些工作负载,即使是更大的 shared_buffers 设置也可能有效,但由于 PostgreSQL 也依赖于操作系统缓存,因此将超过 40% 的 RAM 分配给 shared_buffers 不可能比分配较少量的 RAM 效果更好。较大的 shared_buffers 设置通常需要相应地增加 max_wal_size,以将大量新数据或已更改数据的写入过程分散到更长的时间段内。

在 RAM 少于 1GB 的系统上,分配较小比例的 RAM 是合适的,以便为操作系统留出足够的空间。

huge_pages (enum) #

控制是否为主共享内存区域请求大页。有效值包括 try(默认)、onoffhuge_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 等操作系统也可以自动为普通内存分配使用大页(也称为“super”页或“large”页),而无需 PostgreSQL 的显式请求。在 Linux 上,这被称为“透明大页 (THP)。该功能已知会导致某些 Linux 版本上的 PostgreSQL 用户性能下降,因此目前不鼓励使用它(与显式使用 huge_pages 不同)。

huge_page_size (integer) #

控制大页的大小,当它们通过 huge_pages 启用时。默认值为零(0)。当设置为 0 时,将使用系统默认的大页大小。此参数只能在服务器启动时设置。

现代 64 位服务器架构上一些常见的大页大小包括:2MB1GB(Intel 和 AMD)、16MB16GB(IBM POWER),以及 64kB2MB32MB1GB(ARM)。有关使用和支持的信息,请参阅 第 18.4.5 节

非默认设置目前仅在 Linux 上受支持。

temp_buffers (integer) #

设置每个数据库会话中用于临时缓冲区的最大内存量。这些是仅用于访问临时表的会话本地缓冲区。如果此值未指定单位,则假定为块,即 BLCKSZ 字节,通常为 8KB。默认值为 8MB。(如果 BLCKSZ 不是 8KB,则默认值会与其成比例缩放。)此设置可以在单个会话中更改,但仅限于在该会话首次使用临时表之前;之后尝试更改该值将对该会话无效。

会话将根据需要分配临时缓冲区,最高可达 temp_buffers 指定的限制。设置一个大值给实际不需要大量临时缓冲区的会话的成本仅是每个 temp_buffers 增量大约 64 字节的缓冲区描述符。但是,如果缓冲区实际被使用,将额外消耗 8192 字节(或一般情况下,BLCKSZ 字节)。

max_prepared_transactions (integer) #

同时设置可以处于“准备好”状态(请参阅 PREPARE TRANSACTION)的事务的最大数量。将此参数设置为零(这是默认值)将禁用准备事务功能。此参数只能在服务器启动时设置。

如果您不打算使用准备事务,则应将此参数设置为零,以防止意外创建准备事务。如果您正在使用准备事务,您可能希望 max_prepared_transactions 至少与 max_connections 一样大,以便每个会话都可以有一个待处理的准备事务。

运行备用服务器时,必须将此参数设置为与主服务器相同或更高的值。否则,将不允许在备用服务器上执行查询。

work_mem (integer) #

设置查询操作(如排序或哈希表)在写入临时磁盘文件之前使用的最大内存量。如果此值未指定单位,则假定为千字节。默认值为 4MB。请注意,复杂的查询可能同时执行多个排序和哈希操作,每个操作通常允许使用此值指定的内存量,然后才开始将数据写入临时文件。此外,多个正在运行的会话可以同时执行此类操作。因此,总内存使用量可能是 work_mem 值的许多倍;在选择值时必须牢记这一点。排序操作用于 ORDER BYDISTINCT 和合并联接。哈希表用于哈希联接、基于哈希的聚合、memoize 节点和基于哈希的 IN 子查询处理。

基于哈希的操作通常比等效的基于排序的操作对内存可用性更敏感。哈希表的内存限制通过将 work_mem 乘以 hash_mem_multiplier 来计算。这使得基于哈希的操作可以使用超过通常 work_mem 基准量的内存。

hash_mem_multiplier (floating point) #

用于计算基于哈希的操作可以使用内存的最大量。最终限制通过将 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 (integer) #

指定用于维护操作(如 VACUUMCREATE INDEXALTER TABLE ADD FOREIGN KEY)的最大内存量。如果此值未指定单位,则假定为千字节。默认值为 64MB。由于每个数据库会话一次只能执行其中一项操作,并且一个安装通常不会同时运行许多此类操作,因此将此值设置得远大于 work_mem 是安全的。较大的设置可能会提高 vacuuming 和还原数据库转储的性能。

请注意,当 autovacuum 运行时,可能会分配多达 autovacuum_max_workers 倍的此内存,因此请小心不要将默认值设置得太高。通过单独设置 autovacuum_work_mem 来控制这一点可能很有用。

autovacuum_work_mem (integer) #

指定每个 autovacuum 工作进程使用的最大内存量。如果此值未指定单位,则假定为千字节。默认值为 -1,表示应使用 maintenance_work_mem 的值。此设置不会影响 VACUUM 在其他上下文中的行为。此参数只能在 postgresql.conf 文件中或在服务器命令行中设置。

vacuum_buffer_usage_limit (integer) #

VACUUMANALYZE 命令使用的 缓冲区访问策略的大小。设置为 0 将允许操作使用任意数量的 shared_buffers。否则,有效大小范围为 128KB 到 16GB。如果指定的尺寸超过 shared_buffers 的 1/8,尺寸将被悄悄限制在该值。默认值为 2MB。如果此值未指定单位,则假定为千字节。此参数可随时设置。在传递 BUFFER_USAGE_LIMIT 选项时,可以为 VACUUMANALYZE 覆盖。较高的设置可以使 VACUUMANALYZE 运行得更快,但设置过大可能会导致太多有用的页面从共享缓冲区中被逐出。

logical_decoding_work_mem (integer) #

指定逻辑解码使用的最大内存量,然后将部分解码的更改写入本地磁盘。这限制了逻辑流复制连接使用的内存量。默认值为 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 配置的方法从操作系统临时分配额外的共享内存,这可能会由于内存管理开销而变慢。在支持大页的操作系统上,在服务器启动时使用 min_dynamic_shared_memory 分配的内存会受到 huge_pages 设置的影响,并且可能更有可能从大页中受益。默认值为 0(无)。此参数只能在服务器启动时设置。

19.4.2. 磁盘 #

temp_file_limit (integer) #

指定进程可以为临时文件(如排序和哈希临时文件,或暂存游标的存储文件)使用的最大磁盘空间量。尝试超出此限制的事务将被取消。如果此值未指定单位,则假定为千字节。-1(默认值)表示没有限制。只有超级用户和具有适当 SET 权限的用户才能更改此设置。

此设置限制了给定 PostgreSQL 进程在任何时刻用于所有临时文件的总空间。应注意,用于显式临时表(与查询执行中后台使用的临时文件不同)的磁盘空间不计入此限制。

file_copy_method (enum) #

指定用于复制文件的文件。可能的值包括 COPY(默认)和 CLONE(如果可用)。

此参数影响

  • CREATE DATABASE ... STRATEGY=FILE_COPY

  • ALTER DATABASE ... SET TABLESPACE ...

CLONE 使用 copy_file_range()(Linux、FreeBSD)或 copyfile(macOS)系统调用,让内核有机会共享磁盘块或将工作推送到某些文件系统的较低层。

max_notify_queue_pages (integer) #

指定用于 NOTIFY / LISTEN 队列分配的最大页面数。默认值为 1048576。对于 8KB 的页面,它允许消耗高达 8GB 的磁盘空间。

19.4.3. 内核资源使用 #

max_files_per_process (integer) #

设置每个服务器子进程允许同时打开的最大文件数;在 postmaster 中已打开的文件不计入此限制。默认值为一千个文件。

如果内核强制执行了安全的每个进程限制,则您无需担心此设置。但在某些平台(尤其是大多数 BSD 系统)上,如果许多进程都尝试打开大量文件,内核将允许单个进程打开比系统实际支持的更多的文件。如果您遇到“文件过多”的错误,请尝试减小此设置。此参数只能在服务器启动时设置。

19.4.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) #

每当后台写入器写入超过此量的数据时,尝试强制操作系统将这些写入强制到底层存储。这样做将限制内核页面缓存中的脏数据量,从而降低在检查点结束时发出 fsync 时,或者当操作系统在后台以更大批次写入数据时,出现停顿的可能性。通常这将大大减少事务延迟,但也有一些情况,特别是当工作负载大于 shared_buffers 但小于操作系统页面缓存时,性能可能会下降。此设置在某些平台上可能无效。如果此值未指定单位,则假定为块,即 BLCKSZ 字节,通常为 8KB。有效范围是 0(禁用强制写回)到 2MB。在 Linux 上默认值为 512KB,在其他地方为 0。(如果 BLCKSZ 不是 8KB,则默认值和最大值与其成比例缩放。)此参数只能在 postgresql.conf 文件中或在服务器命令行中设置。

较小的 bgwriter_lru_maxpagesbgwriter_lru_multiplier 值会减少后台写入器引起的额外 I/O 负载,但会增加服务器进程不得不自行执行写入的可能性,从而延迟交互式查询。

19.4.5. 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 停顿,以及对具有高 IOP 的设备。不必要的高值可能会增加系统中所有查询的 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。此参数只能在 postgresql.conf 文件中或在服务器命令行中设置。最大可能大小取决于操作系统和块大小,但在 Unix 上通常为 1MB,在 Windows 上为 128KB。默认值为 128KB。

io_combine_limit (integer) #

控制组合 I/O 操作的最大 I/O 大小。如果设置得高于 io_max_combine_limit 参数,则将悄悄使用较低的值,因此两者可能都需要提高才能增加 I/O 大小。最大可能大小取决于操作系统和块大小,但在 Unix 上通常为 1MB,在 Windows 上为 128KB。默认值为 128KB。

io_max_concurrency (integer) #

控制一个进程可以同时执行的最大 I/O 操作数。

默认设置 -1 会根据 shared_buffers 和最大进程数(max_connectionsautovacuum_worker_slotsmax_worker_processesmax_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 时才有效。

19.4.6. 工作进程 #

max_worker_processes (integer) #

设置集群可以支持的最大后台进程数。此参数只能在服务器启动时设置。默认值为 8。

运行备用服务器时,必须将此参数设置为与主服务器相同或更高的值。否则,将不允许在备用服务器上执行查询。

更改此值时,请考虑同时调整 max_parallel_workersmax_parallel_maintenance_workersmax_parallel_workers_per_gather

max_parallel_workers_per_gather (integer) #

设置单个 GatherGather 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 树、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_workersmax_parallel_workers_per_gather。另外,请注意,此值设置得高于 max_worker_processes 将无效,因为并行工作进程是从由该设置建立的工作进程池中获取的。

parallel_leader_participation (boolean) #

允许主进程在 GatherGather Merge 节点下执行查询计划,而不是等待工作进程。默认值为 on。将此值设置为 off 会降低工作进程因主进程读取元组不够快而阻塞的可能性,但需要主进程等待工作进程启动后才能产生第一个元组。主进程对性能的帮助或阻碍程度取决于计划类型、工作进程数量和查询持续时间。

提交更正

如果您在文档中看到任何不正确之处、与您对特定功能的体验不符之处或需要进一步澄清之处,请使用 此表格 报告文档问题。