pgsql.cc 提供对 postgresql.org 官网内容的中文翻译，由 Pigsty 团队维护。
shared_buffers (integer) #设置数据库服务器用于共享内存缓冲区的内存量。默认值通常为 128 兆字节（128MB），但如果内核设置不支持，则可能更小（在 initdb 期间确定）。此设置必须至少为 128 千字节。（BLCKSZ 的非默认值会改变该最小值。）不过，要获得良好性能，通常需要远高于该最小值的设置。此参数只能在服务器启动时设置。
如果专用数据库服务器具有 1GB 或更多内存，shared_buffers 的合理初始值是系统内存的 25%。对于某些工作负载，将 shared_buffers 设得很大也有效，但由于 PostgreSQL 同时依赖操作系统缓存，将超过 40% 的内存分配给 shared_buffers 不太可能比更小的值效果更好。将 shared_buffers 设得更大时，通常还需要相应增加 checkpoint_segments，以便将大量新数据或已修改数据的写入过程分散到更长的时间内。
对于内存少于 1GB 的系统，适合使用更小的内存比例，以便为操作系统留出足够空间。另外，在 Windows 上，很大的 shared_buffers 设置并不那么有效。让该设置保持相对较低、更多地使用操作系统缓存，可能得到更好的结果。Windows 系统上 shared_buffers 的有效范围通常是从 64MB 到 512MB。
huge_pages (enum) #启用或禁用巨型内存页。有效值为 try（默认值）、on 和 off。
目前只有 Linux 支持此特性。在其他系统上，设置为 try 时会忽略此设置。
使用巨型页可缩小页表，减少内存管理所需的 CPU 时间，从而提高性能。更多信息参见 第 17.4.5 节。
将 huge_pages 设为 try 时，服务器会尝试使用巨型页，失败后则回退到普通内存分配。设为 on 时，使用巨型页失败会导致服务器无法启动。设为 off 时，不使用巨型页。
temp_buffers (integer) #设置每个数据库会话使用的临时缓冲区的最大数量。这些是会话本地的缓冲区，仅用于访问临时表。默认值为 8 兆字节（8MB）。可以在单个会话内更改此设置，但必须在该会话首次使用临时表之前更改；此后尝试更改该值，对该会话不会产生影响。
会话会按需分配临时缓冲区，上限为 temp_buffers。对于实际不需要很多临时缓冲区的会话，将此参数设得较大时，开销仅为 temp_buffers 每增加一就多分配一个缓冲区描述符，约为 64 字节。不过，如果实际使用了某个缓冲区，还会为它额外消耗 8192 字节（一般而言为 BLCKSZ 字节）。
max_prepared_transactions (integer) #设置可同时处于“预备”状态的事务的最大数量（见 PREPARE TRANSACTION）。将此参数设为零（默认值）会禁用预备事务功能。此参数只能在服务器启动时设置。
如果不打算使用预备事务，应将此参数设为零，以防意外创建预备事务。如果使用预备事务，通常应将 max_prepared_transactions 设为不小于 max_connections 的值，以便每个会话都能有一个待处理的预备事务。
运行备库时，必须将此参数设为与主库相同或更大的值。否则，备库上将不允许执行查询。
work_mem (integer) #指定内部排序操作和哈希表在写入临时磁盘文件之前可使用的内存量。默认值为 4 兆字节（4MB）。请注意，复杂查询可能并行执行多个排序或哈希操作，每个操作在开始向临时文件写入数据之前，都可以使用此值指定的内存量。此外，多个正在运行的会话也可能并发执行此类操作。因此，使用的总内存量可能是 work_mem 值的数倍；选择此值时必须考虑这一点。排序操作用于 ORDER BY、DISTINCT 和归并连接。哈希表用于哈希连接、基于哈希的聚合、以及基于哈希的 IN 子查询处理。
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 的行为。
max_stack_depth (integer) #指定服务器执行栈的最大安全深度。此参数的理想设置是由内核强制执行的实际栈大小限制 （如由ulimit -s或本地等效设置），减去大约一兆字节的安全余量。 需要安全余量是因为服务器中并非每个例程都检查栈深度，而只在可能递归的关键例程（如表达式求值）中检查。 默认设置为两兆字节（2MB）， 这是保守且不太可能引起崩溃的小值。但是，这可能太小，无法执行复杂函数。 只有超级用户才能更改此设置。
把max_stack_depth参数设置得高于实际的内核限制将意味着一个失控的递归函数可能会导致一个独立的后端进程崩溃。 在PostgreSQL能够检测内核限制的平台上， 服务器将不允许把这个参数设置为一个不安全的值。不过，并非所有平台都能提供该信息，所以我们还是建议你在选择值时要小心。
dynamic_shared_memory_type (enum) #指定服务器应使用的动态共享内存实现。可选值为 posix（使用 shm_open 分配的 POSIX 共享内存）、sysv（通过 shmget 分配的 System V 共享内存）、windows（Windows 共享内存）、mmap（使用存放在数据目录中的内存映射文件模拟共享内存），以及 none（禁用此功能）。并非所有平台都支持所有值；第一个受支持的选项是该平台的默认值。mmap 不是任何平台的默认选项，通常不建议使用，因为操作系统可能会反复将修改过的页面写回磁盘，增加系统 I/O 负载；不过，在调试、将 pg_dynshmem 目录存放在 RAM 磁盘上，或其他共享内存设施不可用时，它可能有用。
temp_file_limit (integer) #指定一个会话可用于临时文件的最大磁盘空间，例如排序和哈希临时文件，或保留游标的存储文件。尝试超过此限制的事务将被取消。该值以千字节为单位。-1（默认值）表示没有限制。只有超级用户才能更改此设置。
此设置限制单个 PostgreSQL 会话在任意时刻使用的所有临时文件的总空间。需要注意，显式临时表所用的磁盘空间不计入该上限；计入的是查询执行过程中内部使用的临时文件。
max_files_per_process (integer) #设置每个服务器子进程允许同时打开的最大文件数量。默认值为一千个文件。如果内核强制实施了安全的每进程上限，就不必担心此设置。但在某些平台上（尤其是大多数 BSD 系统），内核允许单个进程打开的文件数量很大，如果很多进程都尝试打开这么多文件，就会远超系统实际能够支持的总量。如果遇到 “Too many open files”（打开的文件过多）错误，可尝试减小此设置。此参数只能在服务器启动时设置。
执行 VACUUM 和 ANALYZE 命令期间，系统维护一个内部计数器，记录已执行的各种 I/O 操作的估算代价。 当累计代价达到上限（由 vacuum_cost_limit 指定）时，执行该操作的进程会休眠一小段时间，时长由 vacuum_cost_delay 指定。 随后重置计数器并继续执行。
此功能让管理员能够降低这些命令对并发数据库活动的 I/O 影响。在许多情况下，VACUUM 和 ANALYZE 等维护命令是否快速完成并不重要， 但避免它们显著干扰系统执行其他数据库操作的能力通常很重要。基于代价的清理延迟为管理员提供了实现这一点的方法。
对于手动执行的 VACUUM 命令，此功能默认禁用。要启用它，将 vacuum_cost_delay 变量设为非零值。
vacuum_cost_delay (integer) #超过代价上限后，进程将休眠的时长，单位为毫秒。默认值为零，表示禁用基于代价的清理延迟功能。正值会启用基于代价的清理。注意，在许多系统上，休眠延迟的有效分辨率为 10 毫秒；将 vacuum_cost_delay 设为不是 10 的倍数的值，可能与将它设为下一个更大的 10 的倍数效果相同。
使用基于代价的清理时，vacuum_cost_delay 的合适值通常较小，例如 10 或 20 毫秒。调整清理的资源消耗时，最好更改其他清理代价参数。
vacuum_cost_page_hit (integer) #清理在共享缓冲区缓存中找到的缓冲区时所计入的估算代价。它表示锁定缓冲池、查找共享哈希表和扫描页内容的代价。默认值为 1。
vacuum_cost_page_miss (integer) #清理必须从磁盘读取的缓冲区时所计入的估算代价。它表示锁定缓冲池、查找共享哈希表、从磁盘读取所需数据块并扫描其内容所需的工作量。默认值为 10。
vacuum_cost_page_dirty (integer) #清理操作修改原本干净的数据块时所计入的估算代价。它表示再次将脏块刷盘所需的额外 I/O。默认值为 20。
vacuum_cost_limit (integer) #会使清理进程休眠的累计代价。默认值为 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 (floating point) #每轮写出的脏缓冲区数量取决于最近几轮服务器进程所需的新缓冲区数量。将近期平均需求乘以 bgwriter_lru_multiplier，即可估算下一轮所需的缓冲区数量。写入器会写出脏缓冲区，直到可用的干净且可重用缓冲区达到这一数量。（不过，每轮写出的缓冲区数量不会超过 bgwriter_lru_maxpages。）因此，设为 1.0 表示采用“恰好及时”策略，写出的缓冲区数量恰好等于预测需求量。更大的值可为需求突增留出余量，而更小的值则有意将部分写操作留给服务器进程执行。默认值为 2.0。此参数只能在 postgresql.conf 文件中或服务器命令行上设置。
较小的 bgwriter_lru_maxpages 和 bgwriter_lru_multiplier 可以降低后台写入器造成的额外 I/O 负载， 但也会增加服务器进程必须自行发出写操作的可能性，从而延迟交互式查询。
effective_io_concurrency (integer) #设置 PostgreSQL 预期可以同时执行的并发磁盘 I/O 操作数量。提高此值会增加单个 PostgreSQL 会话尝试并行发起的 I/O 操作数量。允许的范围为 1 至 1000，或设为零以禁用异步 I/O 请求。目前，此设置仅影响位图堆扫描。
对于磁盘，可以将为数据库提供存储的 RAID 0 条带或 RAID 1 镜像中的独立磁盘数量作为合理初始值。（对于 RAID 5，不应计入校验盘。）不过，如果数据库经常忙于执行并发会话发出的多个查询，较小的值可能就足以使磁盘阵列保持繁忙。超过使磁盘保持繁忙所需的值只会增加 CPU 开销。
对于更特殊的系统，例如基于内存的存储或受总线带宽限制的 RAID 阵列，正确的值可能是可用 I/O 通路的数量。可能需要一些实验才能找到最佳值。
异步 I/O 依赖于有效的 posix_fadvise 函数，而某些操作系统缺少此函数。如果该函数不存在，将此参数设为任何非零值都会报错。在某些操作系统（如 Solaris）上，该函数虽然存在，却实际上不做任何事情。
max_worker_processes (integer) #设置系统能够支持的后台进程的最大数量。此参数只能在服务器启动时设置。
运行备库时，必须将此参数设为与主库相同或更大的值。否则，备库上将不允许执行查询。
译文有误、术语不当或页面显示问题，请到译文仓库 pgsty/pgdoc 报告译文问题。 英文原文本身的问题，请在当前版本的对应页面向上游反馈；上游不再修订已结束维护的版本。