pgsql.cc 提供对 postgresql.org 官网内容的中文翻译，由 Pigsty 团队维护。
shared_buffers (integer) #设置数据库服务器用于共享内存缓冲区的内存量。默认值通常为 32 兆字节（32MB），但如果内核设置不支持，则可能更小（在 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。
增加这个参数可能会导致PostgreSQL请求比你的操作系统默认配置所允许的更多的System V共享内存。如果有必要，关于如何调整那些参数的信息见第 17.4.1 节。
temp_buffers (integer) #设置每个数据库会话使用的临时缓冲区的最大数量。这些是会话本地的缓冲区，仅用于访问临时表。默认值为 8 兆字节（8MB）。可以在单个会话内更改此设置，但必须在该会话首次使用临时表之前更改；此后尝试更改该值，对该会话不会产生影响。
会话会按需分配临时缓冲区，上限为 temp_buffers。对于实际不需要很多临时缓冲区的会话，将此参数设得较大时，开销仅为 temp_buffers 每增加一就多分配一个缓冲区描述符，约为 64 字节。不过，如果实际使用了某个缓冲区，还会为它额外消耗 8192 字节（一般而言为 BLCKSZ 字节）。
max_prepared_transactions (integer) #设置可同时处于“预备”状态的事务的最大数量（见 PREPARE TRANSACTION）。将此参数设为零（默认值）会禁用预备事务功能。此参数只能在服务器启动时设置。
如果不打算使用预备事务，应将此参数设为零，以防意外创建预备事务。如果使用预备事务，通常应将 max_prepared_transactions 设为不小于 max_connections 的值，以便每个会话都能有一个待处理的预备事务。
增加这个参数可能会导致PostgreSQL请求比你的操作系统默认配置所允许的更多的System V共享内存。如果有必要，关于如何调整那些参数的信息见第 17.4.1 节。
当运行一个备库时，你必须设置这个参数等于或大于主库上的参数。 否则，备库上将不允许查询。
work_mem (integer) #指定内部排序操作和哈希表在写入临时磁盘文件之前可使用的内存量。默认值为 1 兆字节（1MB）。请注意，复杂查询可能并行执行多个排序或哈希操作，每个操作在开始向临时文件写入数据之前，都可以使用此值指定的内存量。此外，多个正在运行的会话也可能并发执行此类操作。因此，使用的总内存量可能是 work_mem 值的数倍；选择此值时必须考虑这一点。排序操作用于 ORDER BY、DISTINCT 和归并连接。哈希表用于哈希连接、基于哈希的聚合、以及基于哈希的 IN 子查询处理。
maintenance_work_mem (integer) #指定维护操作（如 VACUUM、CREATE INDEX 和 ALTER TABLE ADD FOREIGN KEY）可使用的最大内存量。默认值为 16 兆字节（16MB）。由于一个数据库会话一次只能执行一个此类操作，而一个数据库系统通常也不会并发运行很多此类操作，因此可以安全地将该值设得远大于 work_mem。更大的设置可能改善清理和恢复数据库转储的性能。
注意，自动清理运行时，最多可能分配此内存量的 autovacuum_max_workers 倍，因此不要将默认值设得过高。
max_stack_depth (integer) #指定服务器执行栈的最大安全深度。此参数的理想设置是由内核强制执行的实际栈大小限制 （如由ulimit -s或本地等效设置），减去大约一兆字节的安全余量。 需要安全余量是因为服务器中并非每个例程都检查栈深度，而只在可能递归的关键例程（如表达式求值）中检查。 默认设置为两兆字节（2MB）， 这是保守且不太可能引起崩溃的小值。但是，这可能太小，无法执行复杂函数。 只有超级用户才能更改此设置。
把max_stack_depth参数设置得高于实际的内核限制将意味着一个失控的递归函数可能会导致一个独立的后端进程崩溃。 在PostgreSQL能够检测内核限制的平台上， 服务器将不允许把这个参数设置为一个不安全的值。不过，并非所有平台都能提供该信息，所以我们还是建议你在选择值时要小心。
max_files_per_process (integer) #设置每个服务器子进程允许同时打开的最大文件数量。默认值为一千个文件。如果内核强制实施了安全的每进程上限，就不必担心此设置。但在某些平台上（尤其是大多数 BSD 系统），内核允许单个进程打开的文件数量很大，如果很多进程都尝试打开这么多文件，就会远超系统实际能够支持的总量。如果遇到 “Too many open files”（打开的文件过多）错误，可尝试减小此设置。此参数只能在服务器启动时设置。
shared_preload_libraries (string) #这个变量指定一个或者多个要在服务器启动时预载入的共享库。例如， '$libdir/mylib'会使 mylib.so（或者在某些平台上的 mylib.sl）从安装的标准库目录中被预载入。 除非用双引号括起，所有库名都会被转换为小写。如果要载入多个库，库名之间用逗号分隔。 这个参数只能在服务器启动时设置。
可以用这个方法预装载PostgreSQL的过程语言库，通常是使用'$libdir/plXXX'语法，其中的XXX是pgsql、perl、tcl或python。
通过预载入一个共享库，当该库被第一次使用时就可以避免库的启动时间。 不过，启动每个新服务器进程的时间可能会略有增加，即使该进程从不使用该库。 因此，推荐只把这个参数用于那些要在大多数会话中使用的库上。
在 Windows 主机上，在服务器启动时预载入一个库并不会减少启动每个新服务器进程所需 的时间；每一个服务器进程将会重新载入所有预载入的库。不过，shared_preload_libraries 在 Windows 主机上仍然有用，因为某些共享库可能需要执行一些只在 postmaster 启动时发生的操作，例如分配共享内存、保留轻量级锁或者启动后台工作者。
如果指定的库没有找到，服务器将无法启动。
每一个 PostgreSQL 支持的库都有一个“魔法块”，它会被检查以保证兼容性。 由于这个原因，非 PostgreSQL 的库不能以这种方式载入。
执行 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毫秒，再重复此过程。默认值为 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）上，该函数虽然存在，却实际上不做任何事情。
译文有误、术语不当或页面显示问题，请到译文仓库 pgsty/pgdoc 报告译文问题。 英文原文本身的问题，请在当前版本的对应页面向上游反馈；上游不再修订已结束维护的版本。