©
本文檔使用 php中文網手册 發布
设置数据库服务器将使用的共享内存缓冲区数量。缺省通常是 4000(32MB)， 如果内核设置不支持这么大，那么可以少些(在initdb的时候决定)。 每个缓冲区大小的典型值是 8192 字节，除非你在编译的时候修改了 BLCKSZ的值。这个数值必须大于 16 ，并且至少是 max_connections 数值的两倍；不过，这个数值大一些通常可以改进性能。对于生产安装， 我们通常建议至少是几千。这个选项只能在服务器启动的时候设置。
如果有专用的1GB或更多内存的数据库服务器，一个合理的shared_buffers开始值可以是25%。 shared_buffers即使设置的很大，并且有效，同样会造成一些工作负载， 但因为PostgreSQL同样依赖操作系统缓冲区，shared_buffers 这是超过40%RAM不可能比一个小点值运行更快。为了在一个较长的时间里能更好的写大量的新数据或修改旧数据， shared_buffers设置的越大， checkpoint_segments也会越大。
如果操作系统内存小于1GB，相应的内存要求也会降低，以为操作系统留下足够的空间。 同时，在Windows上，shared_buffers设置的较大也不一定有效。 保持相对低的设置，同时使用更多的操作系统缓冲，此时可能会有不错的效果。 Windows上可用的shared_buffers值时从64MB到512MB。
增大这个参数可能导致PostgreSQL要求更多 System V共享内存，可能超出操作系统配置 许可的范围。必要时请参阅节Section 17.4.1获取如何调整这些 参数的信息。
设置每个数据库会话使用的临时缓冲区的最大数目。这些都是会话的本地缓冲 区，只用于访问临时表。缺省是 1000(8MB) 。这个设置可以在 独立的会话内部设置，但是只有在会话第一次使用临时表的时候才能增长； 企图在该会话里随后改变该数值是无效的。
一个会话将按照temp_buffers给出的限制，根据需要分配临时 缓冲区。如果在一个并不需要大量临时缓冲区的会话里设置一个大的数值， 其开销只是一个缓冲区描述符，或者说每个temp_buffers 增加大概 64 字节。不过，如果一个缓冲区实际上被使用，那么就会额外消耗 8192 字节(或者说是BLCKSZ字节)。
设置可以同时处于"prepared"状态的事务的最大数目 (参阅PREPARE TRANSACTION)。把这个参数设置 为零（这是默认设置）则关闭预备事务的特性。这个值只能在服务器启动 的时候设置。
如果不打算使用prepared状态的事务，可以把这个参数设置为0，防止意外创建prepared状态的事务。 如果正在使用这种事务，将max_prepared_transactions设置为 max_connections中的值，因此每一个会话可以有一个prepared事务等待。
增加这个参数可能会导致PostgreSQL要求比缺省的操作 系统配置的更多的System V共享内存。 必要时请参阅节16.4.1Section 17.4.1获取有关如何调节这个参数 的信息。
当运行一个备库时，这个参数必须至少与主库上的一样大，否则，备库上将不会执行查询。
声明内部排序操作和 Hash 表在开始使用临时磁盘文件之前使用的内存数目。 数值是以千字节为单位的，缺省是 1024 千字节(1MB)。 请注意对于复杂的查询， 可能会同时并发运行好几个排序或者散列操作；每次运行都会被批准使用这个参数 声明的这么多内存，然后才会开始求助于临时文件。同样，好几个正在运行的 会话可能会同时进行排序操作。因此使用的总内存可能是work_mem 的好几倍。ORDER BY，DISTINCT和融合连接都要 用到排序操作。 Hash 表在散列连接、散列为基础的聚集、散列为基础的 IN子查询处理中都要用到。
声明在维护性操作(比如VACUUM，CREATE INDEX， 和ALTER TABLE ADD FOREIGN KEY等)中使用的 最大的内存数。数值是用千字节计的，缺省是 16384 千字节 (16MB)。因为在一个数据库会话里，任意时刻只有一个这样的 操作可以执行，并且一个数据库安装通常不会有太多这样的工作并发执行， 把这个数值设置得比work_mem更大是安全的。 更大的设置可以改进清理和恢复数据库转储的速度。
需要注意的是，当自动vacuum运行时，达到autovacuum_max_workers的时间，这个内存会被分配， 因此不要讲缺省值设置很大。
声明服务器的执行堆栈的最大安全深度。为此设置一个参数的原因是内核强制 的实际堆栈尺寸(就是ulimit -s或者局部等效物的设置)小于 安全的一兆字节左右的范围。需要这个安全界限是因为在服务器里，并非所有 过程都检查了堆栈深度，只是在可能递规的过程，比如表达式计算这样的过程 里面才进行检查。缺省设置是 2048kB(2MB)，这个值相对比较小 ，不容易导致崩溃。但是，这个值可能太小了，以至于无法执行复杂的函数。
把max_stack_depth参数设置得大于实际的内核限制意味着一个 正在运行的递归函数可能会导致一个独立的服务器进程的崩溃。 在PostgreSQL能够检测内核限制的平台上， 将不允许你将其设置为一个不安全的值。因为并非所有平台都能够检测， 所以还是建议你在此设置一个明确的值。
设置每个服务器进程允许同时打开的最大文件数目。缺省是 1000 。 如果内核强制一个合理的每进程限制，那么你不用操心这个设置。但是在 一些平台上(特别是大多数 BSD 系统)，内核允许独立进程打开比个系统 真正可以支持的数目大得多得文件数。如果你发现有"Too many open files"这样的失败现像，那么就尝试缩小这个设置。这个值只能在服务器 启动的时候设置。
这个变量声明一个或者多个在服务器启动的时候预先装载的共享库启动。 比如'$libdir/mylib'可能会造成mylib.so(或mylib.sl) 从安装的标准库目录预安装。所有库的名字会被转换成小写，除非使用了双引号。 如果载入多个库，那么用逗号将它们的名字隔开。 这个值只能在服务器启动的时候设置。
可以用这个方法预先装载PostgreSQL的过程 语言库，通常是使用'$libdir/plXXX'语法，这里的 XXX是pgsql，perl，tcl，或python之一。
通过预先装载一个共享库(以及在需要的时候初始化它)，我们就可以避免 第一次使用这个库的加载时间。不过，启动每个服务器进程的时间可能会 增加，即使进程从来没有使用过这些库也这样。因此我们只是建议对那些 将被大多数会话使用的库才使用这个选项。
Note: 在Windows主机上，服务器启动时预装库不会减少开始每个新的服务器进程所需的时间； 每个服务器进程会载入所有的预装库。然而，shared_preload_libraries在Windows主机上 仍然是有用的，因为在postmaster启动时，一些共享库可能需要执行某些操作。 （比如，一个共享库可能需要存储轻量级锁或共享内存，而postmaster已经启动后却做不到）。
如果没有找到声明的库，那么服务器启动将失败。
每一个支持 PostgreSQL 的库都有一个"magic block"用于保证兼容性。因此，不支持PostgreSQL的库不能用 这种办法加载。
在VACUUM和ANALYZE命令 执行过程中，系统维护一个内部的记数器，跟踪所执行的各种 I/O 操作的 近似开销。如果积累的开销达到了vacuum_cost_limit 声明的限制，那么执行这个操作的进程将睡眠vacuum_cost_limit 指定的时间。然后它会重置记数器然后继续执行。
这个特性的目的是允许管理员减少这些命令在并发活动的数据库上的 I/O 影响。 比如，像VACUUM和ANALYZE这样 的维护命令并不需要迅速完成，并且不希望它们严重干扰系统执行其它的数据库 操作。基于开销的清理延迟为管理员提供了一个实现这个目的的手段。
这个特性是缺省关闭的。此功能默认情况下禁用手动发出VACUUM 命令，要想打开它，把vacuum_cost_delay变量设置为一个非零值。
以毫秒计的时间长度，如果超过了开销限制，那么进程将睡眠一会儿。 缺省值 0 关闭基于开销的清理延迟特性。正数值打开基于开销的清理。 不过，要注意在许多系统上，睡眠的有效分辨率是 10 毫秒； 把vacuum_cost_delay设置为一个不是 10 的整数倍 的数值与将它设置为下一个 10 的整数倍作用相同。
当使用基于花费的vacuum时，vacuum_cost_delay的适当的值通常很小， 也许是10或20毫秒。通过调整另一个vacuum的cost参数，可以很好的调整vacuum的资源消耗
清理一个在共享缓存里找到的缓冲区的预计开销。它代表锁住缓冲池、 查找共享的 Hash 表、扫描页面内容的开销。缺省值是 1 。
清理一个要从磁盘上读取的缓冲区的预计开销。它代表锁住缓冲池、 查找共享 Hash 表、从磁盘读取需要的数据块、扫描它的内容的开销。 缺省值是 10
清理修改一个原先是干净的块的预计开销。它代表把一个脏的磁盘块再次 刷新到磁盘上的额外开销。缺省值是 20 。
导致清理进程休眠的积累开销。缺省是 200 。
Note: 有些操作会持有关键的锁，并且应该尽快结束。在这样的操作过程中，基于 开销的清理延迟不会发生作用。为了避免在这种情况下的长延时，实际的 延迟是vacuum_cost_delay* accumulated_balance/ vacuum_cost_limit与 vacuum_cost_delay* 4.两者之间的最大值。
有一个独立的服务器进程，叫做background writer，它唯一 的功能就是发出写"脏"共享缓冲区的命令。这么做的目的是让持有用户查询的 服务器进程应该很少或者几乎不等待写动作的发生，因为后端写进程会做 这件事情。这样的安排同样也减少了检查点造成的性能下降。后端写进程将 持续的把脏页面刷新到磁盘上，所以在检查点到来的时候，只有几个页面需要 刷新到磁盘上。但是这样还是增加了 I/O 的总净负荷，因为以前的检查点间隔 里，一个重复弄脏的页面可能只会冲刷一次，而同一个间隔里，后端写进程 可能会写好几次。在大多数情况下，连续的低负荷要比周期性的尖峰负荷好， 但是在本节讨论的参数可以用于按实际需要调节其行为。
声明后端写进程活跃轮回之间的延迟。在每个轮回里，写进程都会为一些脏 的缓冲区发出写操作(可以用下面的参数控制)。然后它就休眠 bgwriter_delay毫秒(缺省值是200ms)， 然后重复动作。 请注意在许多系统上，休眠延时的有效分辨率是 10 毫秒；因此，设置一个 不是10的倍数的数值与把它设置为下一个10的倍数是一样的效果。 这个选项只能在服务器启动的时候或者在postgresql.conf文件里设置。
在每个轮回里，不超过这么多个缓冲区将做为扫描到的即将回收使用的缓冲区 写入磁盘。缺省值是 100 。这个选项只能在服务器启动的时候或者在 postgresql.conf文件里设置。
每一轮要写的脏缓冲区的数目是根据最近几轮服务器进程需要的新的缓冲区的数目。 最近的平均值*bgwriter_lru_multiplier以估算下一轮需要的缓冲区数目。 直到有那许多干净可重用缓冲区时，脏缓冲区写入 （然而，达不到bgwriter_lru_maxpages时，会在每一轮都写入）。 因此，设置为1.0表示要写入的，预计需要的缓冲区的准确数目的时间策略。 较大的值可以提供在需求高峰时的一个缓冲，而较小的值则需要服务进程来处理一些写操作。 缺省值是2.0。这个选项只能在服务器启动的时候或者在postgresql.conf 文件里设置。
较小的bgwriter_lru_maxpages和bgwriter_lru_multiplier 可以降低由bgwriter进程造成的额外的I/O开销。但更可能的是，服务器进程自己进行问题写入，拖延了交互式查询。
设置并发磁盘I/O操作的数量，那么一些任务可以同时执行。 调高这个值，可以增加I/O操作的数目（试图发起并行连接会话的数目）。 允许的范围是1到100，或0（禁用异步I/O请求）。
一个很好的设置是组成一个RAID 0条带或RAID 1镜像用于数据库的单独的驱动器数量。 （对RAID 5而言，不应计入的奇偶校验驱动器）然而， 如果数据库忙于在并发会话中多个查询，较低的值可能会使磁盘阵列繁忙。一个比 保持磁盘工作的需要值更高的值只会造成额外的CPU开销。
对特殊的系统（如，总线带宽限制基于内存的存储或RAID阵列）来说，有效值可能是 可用的I/O路径数。当然，需要一些实验来找出最佳值。
异步I/O是居于一个有效的posix_fadvise函数（一些操作系统可能没有）
如果没有这个函数，那么这个参数设置为0。在一些操作系统上（如Solaris），虽然提供了
这个函数，但它不会做任何事情。
