设置数据库服务器用于共享内存缓冲区的内存量。默认值通常为 128 兆字节（128MB），但如果内核设置不支持，则可能更小（在 initdb 期间确定）。此设置必须至少为 128 千字节。不过，要获得良好性能，通常需要远高于该最小值的设置。如果指定值时没有单位，则以块为单位，即 BLCKSZ 字节，通常为 8kB。（BLCKSZ 的非默认值会改变该最小值。）此参数只能在服务器启动时设置。

如果专用数据库服务器具有 1GB 或更多内存，shared_buffers 的合理初始值是系统内存的 25%。对于某些工作负载，将 shared_buffers 设得更大也有效，但由于 PostgreSQL 同时依赖操作系统缓存，将超过 40% 的内存分配给 shared_buffers 不太可能比更小的值效果更好。将 shared_buffers 设得更大时，通常还需要相应增加 max_wal_size，以便将大量新数据或已修改数据的写入过程分散到更长的时间内。

对于内存少于 1GB 的系统，适合使用更小的内存比例，以便为操作系统留出足够空间。

控制是否为主共享内存区域请求巨型页。有效值是 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_pages 启用巨型页时所使用的页大小。默认值为零（0）。设置为 0 时，使用系统默认的巨型页大小。此参数只能在服务器启动时设置。

现代 64 位服务器体系结构上常见的页大小包括：2MB 和 1GB（Intel 和 AMD），16MB 和 16GB（IBM POWER），以及 64kB、2MB、32MB 和 1GB（ARM）。关于使用和支持的更多信息，参见第 18.4.5 节。

目前只有 Linux 支持非默认设置。

设置每个数据库会话用于临时缓冲区的最大内存量。这些是会话本地的缓冲区，仅用于访问临时表。如果指定值时没有单位，则以块为单位，即 BLCKSZ 字节，通常为 8kB。默认值为 8 兆字节（8MB）。（如果 BLCKSZ 不是 8kB，则默认值按比例变化。）可以在单个会话内更改此设置，但必须在该会话首次使用临时表之前更改；此后尝试更改该值，对该会话不会产生影响。

会话会按需分配临时缓冲区，上限为 temp_buffers。对于实际不需要很多临时缓冲区的会话，将此参数设得较大时，开销仅为 temp_buffers 每增加一就多分配一个缓冲区描述符，约为 64 字节。不过，如果实际使用了某个缓冲区，还会为它额外消耗 8192 字节（一般而言为 BLCKSZ 字节）。

设置可同时处于“预备”状态的事务的最大数量（见 PREPARE TRANSACTION）。将此参数设为零（默认值）会禁用预备事务功能。此参数只能在服务器启动时设置。

如果不打算使用预备事务，应将此参数设为零，以防意外创建预备事务。如果使用预备事务，通常应将 max_prepared_transactions 设为不小于 max_connections 的值，以便每个会话都能有一个待处理的预备事务。

运行备库时，必须将此参数设为与主库相同或更大的值。否则，备库上将不允许执行查询。

设置查询操作（如排序或 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 的操作可以使用的最大内存量。最终上限由 work_mem 乘以 hash_mem_multiplier 确定。默认值为 2.0，使基于 hash 的操作可以使用通常的 work_mem 基础量的两倍。

如果查询操作经常溢写磁盘，可以考虑增加 hash_mem_multiplier，尤其是在单纯增加 work_mem 会导致内存压力的情况下（内存压力通常表现为间歇性的内存不足错误）。对于混合工作负载，默认值 2.0 通常有效。如果 work_mem 已增加到 40MB 或更高，则将该值进一步设为 2.0 - 8.0 或更高可能有效。

指定维护操作（如 VACUUM、CREATE INDEX 和 ALTER TABLE ADD FOREIGN KEY）可使用的最大内存量。如果未指定单位，则以千字节为单位。默认值为 64 兆字节（64MB）。由于一个数据库会话一次只能执行一个此类操作，而一个数据库系统通常也不会并发运行很多此类操作，因此可以安全地将该值设得远大于 work_mem。更大的设置可能改善清理和恢复数据库转储的性能。

注意，自动清理运行时，最多可能分配此内存量的 autovacuum_max_workers 倍，因此不要将默认值设得过高。单独设置 autovacuum_work_mem 可能有助于控制这一点。

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

指定 VACUUM 和 ANALYZE 命令使用的缓冲区访问策略的大小。设为 0 时，允许操作使用任意数量的 shared_buffers 缓冲区。否则，有效大小范围为 128 kB 至 16 GB。如果指定的大小超过 shared_buffers 大小的 1/8，则会在不提示的情况下限制为该值。默认值为 2MB。如果未指定单位，则以千字节为单位。此参数可以随时设置。在执行 VACUUM 和 ANALYZE 时，可以通过 BUFFER_USAGE_LIMIT 选项覆盖此设置。较大的设置可能使 VACUUM 和 ANALYZE 运行得更快，但设置过大可能会将过多其他有用页面逐出共享缓冲区。

指定逻辑解码在将部分已解码的更改写入本地磁盘之前可使用的最大内存量。它限制了流式逻辑复制连接使用的内存量。默认值为 64 兆字节（64MB）。由于每个复制连接仅使用一个此大小的缓冲区，而一个数据库系统通常不会同时有很多此类连接（受 max_wal_senders 限制），因此可以安全地将该值设得远高于 work_mem，以减少写入磁盘的已解码更改数量。

指定用于缓存 pg_commit_ts 内容的内存量（参见表 66.1）。如果未指定单位，则视为块，即 BLCKSZ 字节，通常为 8kB。默认值为 0，这会请求 shared_buffers/512，最多 1024 个块、最少 16 个块。此参数只能在服务器启动时设置。

指定用于缓存 pg_multixact/members 内容的共享内存量（参见表 66.1）。如果未指定单位，则视为块，即 BLCKSZ 字节，通常为 8kB。默认值为 32。此参数只能在服务器启动时设置。

指定用于缓存 pg_multixact/offsets 内容的共享内存量（参见表 66.1）。如果未指定单位，则视为块，即 BLCKSZ 字节，通常为 8kB。默认值为 16。此参数只能在服务器启动时设置。

指定用于缓存 pg_notify 内容的共享内存量（参见表 66.1）。如果未指定单位，则视为块，即 BLCKSZ 字节，通常为 8kB。默认值为 16。此参数只能在服务器启动时设置。

指定用于缓存 pg_serial 内容的共享内存量（参见表 66.1）。如果未指定单位，则视为块，即 BLCKSZ 字节，通常为 8kB。默认值为 32。此参数只能在服务器启动时设置。

指定用于缓存 pg_subtrans 内容的共享内存量（参见表 66.1）。如果未指定单位，则视为块，即 BLCKSZ 字节，通常为 8kB。默认值为 0，这会请求 shared_buffers/512，最多 1024 个块、最少 16 个块。此参数只能在服务器启动时设置。

指定用于缓存 pg_xact 内容的共享内存量（参见表 66.1）。如果未指定单位，则视为块，即 BLCKSZ 字节，通常为 8kB。默认值为 0，这会请求 shared_buffers/512，最多 1024 个块、最少 16 个块。此参数只能在服务器启动时设置。

指定服务器执行栈的最大安全深度。此参数的理想设置是由内核强制执行的实际栈大小限制（如由 ulimit -s 或本地等效设置），减去大约一兆字节的安全余量。需要安全余量是因为服务器中并非每个例程都检查栈深度，而只在关键的潜在递归例程中检查。如果未指定单位，则将其视为千字节。默认设置为两兆字节（2MB），这是保守且不太可能引起崩溃的小值。但是，这可能太小，无法执行复杂函数。只有超级用户和具有适当 SET 权限的用户才能更改此设置。

把 max_stack_depth 参数设置得高于实际的内核限制将意味着一个失控的递归函数可能会导致一个独立的后端进程崩溃。在 PostgreSQL 能够检测内核限制的平台上，服务器将不允许把这个参数设置为一个不安全的值。不过，并非所有平台都能提供该信息，所以我们还是建议你在选择值时要小心。

指定服务器用于主共享内存区域的共享内存实现，该区域存放 PostgreSQL 的共享缓冲区及其他共享数据。可选值为 mmap（使用 mmap 分配的匿名共享内存）、sysv（通过 shmget 分配的 System V 共享内存）和 windows（Windows 共享内存）。并非所有平台都支持所有值；第一个受支持的选项是该平台的默认值。sysv 不是任何平台的默认选项，通常不建议使用，因为它一般需要更改内核的默认设置才能分配大量内存（见第 18.4.1 节）。此参数只能在服务器启动时设置。

指定服务器应使用的动态共享内存实现。可选值为 posix（使用 shm_open 分配的 POSIX 共享内存）、sysv（通过 shmget 分配的 System V 共享内存）、windows（Windows 共享内存）、mmap（使用存放在数据目录中的内存映射文件模拟共享内存）。并非所有平台都支持所有值；第一个受支持的选项通常是该平台的默认值。mmap 不是任何平台的默认选项，通常不建议使用，因为操作系统可能会反复将修改过的页面写回磁盘，增加系统 I/O 负载；不过，在调试、将 pg_dynshmem 目录存放在 RAM 磁盘上，或其他共享内存设施不可用时，它可能有用。此参数只能在服务器启动时设置。

指定服务器启动时为并行查询分配的内存量。当此内存区域不足或被并发查询耗尽时，新的并行查询会尝试使用 dynamic_shared_memory_type 配置的方法，临时向操作系统分配额外的共享内存；由于内存管理开销，这可能较慢。在支持 huge_pages 设置的操作系统上，启动时通过 min_dynamic_shared_memory 分配的内存会受到该设置的影响；在自动管理巨型页的操作系统上，这些内存也可能更容易受益于较大的页。默认值为 0（不分配）。此参数只能在服务器启动时设置。

指定一个进程可用于临时文件的最大磁盘空间，例如排序和 hash 临时文件，或保留游标的存储文件。尝试超过此限制的事务将被取消。如果未指定单位，则以千字节为单位。-1（默认值）表示没有限制。只有超级用户和具有适当 SET 权限的用户才能更改此设置。

此设置限制单个 PostgreSQL 进程在任意时刻使用的所有临时文件的总空间。需要注意，显式临时表所用的磁盘空间不计入该上限；计入的是查询执行过程中内部使用的临时文件。

指定用于复制文件的方法。可能的值包括 COPY（默认）和 CLONE（如果操作系统支持）。

此参数会影响：

CLONE 使用 copy_file_range()（Linux、FreeBSD）或 copyfile（macOS）系统调用，使内核有机会在某些文件系统上共享磁盘块，或将工作交由更低层处理。

指定在诸如 COPY 这类批量操作期间扩展数据文件时所使用的方法。默认会根据操作系统选择第一个可用选项：

当数据文件扩展的块数不超过 8 个时，总是使用 write_zeros 方法。

指定 NOTIFY / LISTEN 队列可分配页面的最大数量。默认值是 1048576。对于 8 KB 页面，这允许最多消耗 8 GB 的磁盘空间。此参数只能在服务器启动时设置。

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

如果内核强制实施了安全的每进程上限，就不必担心此设置。但在某些平台上（尤其是大多数 BSD 系统），内核允许单个进程打开的文件数量很大，如果很多进程都尝试打开这么多文件，就会远超系统实际能够支持的总量。如果遇到“Too many open files”（打开的文件过多）错误，可尝试减小此设置。此参数只能在服务器启动时设置。

指定后台写入器各轮活动之间的延迟。每一轮中，写入器会对一定数量的脏缓冲区发出写操作（由下面的参数控制），然后休眠 bgwriter_delay 指定的时长，再重复此过程。不过，当缓冲池中没有脏缓冲区时，它会进入更长的休眠，而不受 bgwriter_delay 限制。如果未指定单位，则以毫秒为单位。默认值为 200 毫秒（200ms）。注意，在某些系统上，休眠延迟的有效分辨率为 10 毫秒；将 bgwriter_delay 设为不是 10 的倍数的值，可能与将它设为下一个更大的 10 的倍数效果相同。此参数只能在 postgresql.conf 文件中或服务器命令行上设置。

后台写入器每轮写出的缓冲区数量不会超过此值。设为零会禁用后台写入。（由另一个独立的专用辅助进程管理的检查点不受影响。）默认值为 100 个缓冲区。此参数只能在 postgresql.conf 文件中或服务器命令行上设置。

每轮写出的脏缓冲区数量取决于最近几轮服务器进程所需的新缓冲区数量。将近期平均需求乘以 bgwriter_lru_multiplier，即可估算下一轮所需的缓冲区数量。写入器会写出脏缓冲区，直到可用的干净且可重用缓冲区达到这一数量。（不过，每轮写出的缓冲区数量不会超过 bgwriter_lru_maxpages。）因此，设为 1.0 表示采用“恰好及时”策略，写出的缓冲区数量恰好等于预测需求量。更大的值可为需求突增留出余量，而更小的值则有意将部分写操作留给服务器进程执行。默认值为 2.0。此参数只能在 postgresql.conf 文件中或服务器命令行上设置。

每当后台写入器写出的数据超过此数量时，就尝试强制操作系统将这些写操作发往底层存储。这样可以限制内核页缓存中的脏数据量，降低在检查点结束时调用 fsync，或操作系统在后台以较大批次写回数据时发生停顿的可能性。通常，这能大幅降低事务延迟，但在某些情况下性能可能下降，尤其是工作负载大于 shared_buffers 而小于操作系统页缓存时。此设置在某些平台上可能没有效果。如果未指定单位，则以块为单位，即 BLCKSZ 字节，通常为 8kB。有效范围为 0（禁用强制写回）至 2MB。Linux 上的默认值为 512kB，其他平台为 0。（如果 BLCKSZ 不是 8kB，默认值和最大值将按比例变化。）此参数只能在 postgresql.conf 文件中或服务器命令行上设置。

每当单个后端写出的数据超过此数量时，就尝试强制操作系统将这些写操作发往底层存储。这样可以限制内核页缓存中的脏数据量，降低在检查点结束时调用 fsync，或操作系统在后台以较大批次写回数据时发生停顿的可能性。通常，这能大幅降低事务延迟，但在某些情况下性能可能下降，尤其是工作负载大于 shared_buffers 而小于操作系统页缓存时。此设置在某些平台上可能没有效果。如果未指定单位，则以块为单位，即 BLCKSZ 字节，通常为 8kB。有效范围为 0（禁用强制写回）至 2MB。默认值为 0，即不强制写回。（如果 BLCKSZ 不是 8kB，最大值将按比例变化。）

设置 PostgreSQL 预期可以同时执行的并发存储 I/O 操作数量。提高此值会增加单个 PostgreSQL 会话尝试并行发起的 I/O 操作数量。允许的范围为 1 至 1000，或设为 0 以禁用异步 I/O 请求。默认值为 16。

较高的值对以下存储影响最大：查询原本会出现明显 I/O 停顿的高延迟存储，以及高 IOPS 设备。不必要地设得过高，可能会增加系统中所有查询的 I/O 延迟。

在支持预取建议的系统上，effective_io_concurrency 还控制预取距离。

对于位于特定表空间中的表，可以通过设置同名的表空间参数覆盖此值（见 ALTER TABLESPACE）。

与 effective_io_concurrency 类似，但用于为多个客户端会话执行的维护工作。

默认值为 16。对于位于特定表空间中的表，可以通过设置同名的表空间参数覆盖此值（见 ALTER TABLESPACE）。

控制合并 I/O 操作时允许的最大 I/O 大小，并会静默限制用户可设置的参数 io_combine_limit。该参数只能在服务器启动时设置。如果该值未指定单位，则按块计算，也就是 BLCKSZ 字节，通常为 8kB。最大可能值取决于操作系统和块大小，但在 Unix 上通常为 1MB，在 Windows 上通常为 128kB。默认值是 128kB。

控制合并 I/O 操作时允许的最大 I/O 大小。如果设置值高于 io_max_combine_limit 参数，则会静默使用较低的那个值，因此如果要增大 I/O 大小，可能需要同时提高这两个参数。如果该值未指定单位，则按块计算，也就是 BLCKSZ 字节，通常为 8kB。最大可能值取决于操作系统和块大小，但在 Unix 上通常为 1MB，在 Windows 上通常为 128kB。默认值是 128kB。

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

默认设置 -1 会根据 shared_buffers 以及最大进程数（max_connections、autovacuum_worker_slots、max_worker_processes 和 max_wal_senders）来选择一个值，但不会超过 64。

此参数只能在服务器启动时设置。

选择执行异步 I/O 的方法。可能的值有：

默认值为 worker。

此参数只能在服务器启动时设置。

选择要使用的 I/O 工作进程数量。默认值为 3。此参数只能在 postgresql.conf 文件中或服务器命令行中设置。

仅当 io_method 设置为 worker 时才有效。

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

运行备库时，必须将此参数设为与主库相同或更大的值。否则，备库上将不允许执行查询。

更改此值时，也应考虑调整 max_parallel_workers、​max_parallel_maintenance_workers、​max_parallel_workers_per_gather。

设置单个 Gather 或 Gather Merge 节点能够启动的工作进程的最大数量。并行工作进程取自 max_worker_processes 建立的进程池，并受到 max_parallel_workers 的限制。注意，运行时实际可用的工作进程可能不足请求的数量。此时，计划会使用少于预期的工作进程运行，效率可能较低。默认值为 2。设为 0 会禁用并行查询执行。

注意，并行查询消耗的资源可能远多于非并行查询，因为每个工作进程都是完全独立的进程，对系统的影响大致相当于额外增加一个用户会话。选择此设置的值，以及配置其他控制资源使用的设置（如 work_mem）时，都应考虑这一点。work_mem 等资源限制分别应用于每个工作进程，因此所有进程的总资源用量可能远高于单个进程通常的用量。例如，使用 4 个工作进程的并行查询，其 CPU 时间、内存、I/O 带宽等用量可能达到完全不使用工作进程的查询的 5 倍。

并行查询的更多信息参见第 15 章。

设置单个工具命令能够启动的并行工作进程的最大数量。目前，支持使用并行工作进程的工具命令包括：构建 B-树、GIN 或 BRIN 索引时的 CREATE INDEX，以及不带 FULL 选项的 VACUUM。并行工作进程取自 max_worker_processes 建立的进程池，并受到 max_parallel_workers 的限制。注意，运行时实际可用的工作进程可能不足请求的数量。此时，工具操作会使用少于预期的工作进程运行。默认值为 2。设为 0 会禁止工具命令使用并行工作进程。

注意，并行工具命令的内存消耗不应明显高于等效的非并行操作。这与并行查询的策略不同，后者的资源限制通常分别应用于每个工作进程。并行工具命令将 maintenance_work_mem 视为整个工具命令的资源上限，而不论使用多少个并行工作进程。不过，并行工具命令仍可能消耗多得多的 CPU 资源和 I/O 带宽。

设置集簇能够为并行操作提供的工作进程的最大数量。默认值为 8。增大或减小此值时，也应考虑调整 max_parallel_maintenance_workers、max_parallel_workers_per_gather。此外，将此值设得大于 max_worker_processes 没有效果，因为并行工作进程取自该设置建立的工作进程池。

允许领导者进程执行 Gather 和 Gather Merge 节点下的查询计划，而不是等待工作进程。默认值为 on。将此值设置为 off，可以降低工作进程因领导者读取元组不够快而被阻塞的可能性，但在产生第一批元组之前，领导者进程必须等待工作进程启动。领导者对性能的帮助或妨碍程度取决于计划类型、工作进程数量和查询持续时间。