设置数据库服务器将使用的共享内存缓冲区数量。缺省通常是 1000， 如果你的内核设置不支持这么大，那么可以少些（在 initdb 的时候决定）。 每个缓冲区大小的典型值是 8192 字节，除非你在编译的时候修改了 BLCKSZ 的值。这个数值必须大于 16， 并且至少是 max_connections 数值的两倍；不过，这个数值大一些通常可以改进性能。 对于生产安装，我们通常建议是几千。 这个选项只能在服务器启动的时候设置。
增大这个参数可能导致 PostgreSQL 要求更多 System V 的共享内存， 超出你的操作系统配置许可的范围。必要时请参阅 Section 16.4.1 获取如何调整这些参数的信息。
设置每个数据库会话使用的临时缓冲区的最大数目。 这些都是会话的本地缓冲区，只用于访问临时表。缺省是 1000。 这个设置可以再独立的会话内部设置，但是只有在会话第一次使用临时表的时候才能增长； 在该会话里随后的改变该数值的企图将没有作用。
一个会话将按照 temp_buffers 给出的限制，根据需要分配临时缓冲区。 如果在一个并不需要大量临时缓冲区的会话里设置一个大的数值，其开销只是一个缓冲区描述符， 或者说每次 temp_buffers 里的增加大概 64 字节。 不过，如果一个缓冲区实际上被使用，那么就会有额外的 8192 字节为之消耗 （或者，概括来说是 BLCKSZ 字节）。
设置可以同时处于"准备好"状态的事务的最大数目（参阅 PREPARE TRANSACTION）。 把这个参数设置为零则关闭准备好的事务的特性。缺省是 5。 这个选项只能在服务器启动的时候设置。
如果你不使用准备好事务，这个参数也可以设置为零。 如果你使用它们，你可能会需要把 max_prepared_transactions 设置成至少和 max_connections 一样大， 以避免在准备步骤的失败。
增加这个参数可能会导致 PostgreSQL 要求比缺省的操作系统配置的更多的 System V 共享内存。必要时请参阅 Section 16.4.1 获取有关如何调节这个参数的信息。
声明内部排序操作和散列表在开始使用临时磁盘文件之前使用的内存数目。 数值是以千字节为单位的，缺省是 1024 千字节（1 MB）。 请注意对于复杂的查询，可能会同时并发运行好几个排序或者散列操作； 每个都会被批准使用这个参数声明的这么多内存，然后才会开始求助于临时文件。 同样，好几个正在运行的会话可能会同时进行排序操作。因此使用的总内存可能是 work_mem 的好几倍。 在 ORDER BY，DISTINCT，融合连接，以及 CREATE INDEX 里都要用到排序操作。 散列表在散列连接，散列为基础的聚集，以及散列为基础的 IN 子查询处理中都要用到。
声明在维护性操作中使用的最大的内存数，比如 VACUUM， CREATE INDEX，和 ALTER TABLE ADD FOREIGN KEY 等。 数值是用千字节计的，缺省是 16384 千字节（16 MB）。 因为在一个数据库会话里，任意时刻只有一个这样的操作可以执行， 并且一个数据库安装通常不会有太多这样的工作并发执行， 把这个数值设置得比 work_mem 更大是安全的。 更大的设置可以改进清理和恢复数据库转储的速度。
声明服务器的执行堆栈的最大安全深度。为此设置一个参数的原因是内核强制的实际堆栈尺寸（就是 ulimit -s 或者局部等效物的设置），小于一个安全的一兆字节左右的范围。 需要这么一个安全的界限是因为在服务器里，并非所有过程都检查了堆栈深度， 儿只是在可能递规的过程，比如表达式计算这样的过程里面进行检查。 把这个参数设置得大于实际的内核限制讲意味着一个正在跑的递归函数可能会导致一个独立服务器进程的崩溃。 缺省设置是 2048 KB （两兆），这个值相对比较小，不容易导致崩溃。 但是，这个值可能太小了，以至于无法执行复杂的函数。
这些参数控制共享的自由空间映射的尺寸， 自由空间映射太小会导致数据库随着时间推移消耗不合理的磁盘空间， 因为不在映射表里面的自由空间是不能重复使用的；这个时候 PostgreSQL 在需要存储新数据的时候，会向操作系统要求更多的磁盘空间。 一个数据库范围内的 VACUUM VERBOSE 命令的最后几行现实的信息可以帮助判断当前的设置是否足够。 如果当前的设置太低，那么在这样的操作中也会打印一条 NOTICE 信息。
增加这些参数可能导致 PostgreSQL 要求比你的系统的缺省配置允许的更多的 System V 共享内存。必要的话， 参阅 Section 16.4.1 获取有关如何调整这些参数的信息。
设置每个服务器进程允许同时打开的最大的文件数目。缺省是 1000。 如果内核强制一个合理的每进程限制， 那么你不用操心这个设置。但是在一些平台上（特别指出的是，大多数 BSD 系统）， 内河允许独立的进程打开比个系统真正可以支持的数目大的多文件数。 如果你发现有 "Too many open files" 这样的失败现象，那么就尝试缩小这个设置。 这个选项只能在服务器启动时设置。
这个变量声明一个或者多个在服务器启动的时候预先装载的共享库。 可以选择在装载每个库的时候调用一个无参数的初始化函数。 要声明这个函数，可以在库名字后面加一个冒号，然后增加一个初始化函数名字。 比如 '$libdir/mylib:mylib_init' 会预先装载 mylib 并且执行 mylib_init。 如果装载了多过一个库，用逗号分隔它们。
如果没有找到声明的库或者没有找到初始化函数，那么服务器将启动失败。
可以用这个方法预先装载 PostgreSQL 的过程语言库， 通常是使用 '$libdir/plXXX:plXXX_init' 语法，这里的 XXX 是 pgsql，perl，tcl，或者 python。
通过预先装载一个共享库（以及在需要的时候初始化它）， 我们就可以避免第一次使用这个库的那些启动时间。不过，启动每个服务器进程的时间可能会增加， 即使进程从来没有使用过这些库也这样。因此我们只是建议对那些将被大多数会话使用的库才使用这个选项。
在 VACUUM 和 ANALYZE 命令执行过程中， 系统维护一个内部的指针，这个指针跟踪所执行的各种 I/O 操作的近似开销。 如果积累的开销达到了一个限制（通过 vacuum_cost_limit 声明）， 那么执行这个操作的进程将睡眠一会儿（用 vacuum_cost_delay 声明）。 然后它会重置指针然后继续执行。
这个特性的目的时允许管理员减少这些命令在并发活动的数据库上的 I/O 影响。 有些情况下，像 VACUUM 和 ANALYZE 这样的维护命令并不需要迅速完成； 但是，通常都不希望这些命令会严重干扰系统执行其它数据库操作的响应能力。 基于开销的清理延迟为管理员提供了一个实现这个目的的手段。
缺省的时候，这个特性是关闭的。要想打开它，把 vacuum_cost_delay 变量设置为一个非零值。
以毫秒计的时间长度，如果超过了开销限制，那么进程将睡眠一会儿。 缺省值是 0，它关闭基于开销的清理延迟特性。正数值打开基于开销的清理。 不过，要注意在许多系统上，sleep 延迟的有效分辨率是 10 毫秒； 把 vacuum_cost_delay 设置为一个不是 10 的整数倍的数值与将它设置为下一个 10 的整数倍作用相同。
清理一个在共享缓存里找到的缓冲区的预计开销。它代表锁住缓冲池，查找共享的散列表以及扫描页面的内容的开销。 缺省值是 1。
清理一个要从磁盘上读取的缓冲区的估计开销。 这个行为代表锁住缓冲池，查找共享散列表，从磁盘读取需要的数据块以及扫描它的内容的开销。 缺省值是 10。
如果清理修改一个原先是干净的块的预计开销。它需要一个把脏的磁盘块再次冲刷到磁盘上的额外开销。 缺省值是 20。
导致清理进程休眠的积累开销。缺省是 200。
注意: 有些操作会持有关键的锁，并且应该尽快结束。 在这样的操作过程中，基于开销的清理延迟不会发生作用。 为了避免在这种情况下的长延时，实际的延迟是这样计算的： vacuum_cost_delay * accumulated_balance / vacuum_cost_limit 与 vacuum_cost_delay * 4 之间的最大值。
从 PostgreSQL 8.0 开始，就有一个独立的服务器进程，叫做后端写进程， 它唯一的功能就是发出写"脏"共享缓冲区的命令。 这么做的目的是让持有用户查询的服务器进程应该很少或者几乎不等待写动作的发生， 因为后端写进程会做这件事情。这样的安排同样也减少了检查点造成的性能下降。 后端写进程将持续的把脏页面刷新到磁盘上，所以再检查点到来的时候，只有几个页面需要刷新到磁盘上。 但是这样还是增加了 I/O 的总净负荷，因为以前的检查点间隔里，一个重复弄脏的页面可能只会冲刷一次， 而同一个间隔里，后端写进程可能会写好几次。在大多数情况下，连续的低负荷要比周期性的尖峰负荷好， 但是在本节讨论的参数可以用于为本地需要调节其行为。
声明后端写进程活跃回合之间的延迟。在每个回合里，写进程都会为一些脏的缓冲区发出写操作 （可以用下面的参数控制）。 然后它就休眠 bgwriter_delay 毫秒，然后重复动作。缺省值是 200。 请注意在许多系统上，休眠延时的有效分辨率是 10 毫秒；因此，设置 bgwriter_delay 为一个不是 10 的倍数的数值与把它设置为下一个 10 的倍数是一样的效果。 这个选项只能在服务器启动的时候或者 postgresql.conf 文件里设置。
为了减少服务器进程发出自己的写操作的可能，后端写进程尽量写那些可能很快被重复使用的缓冲区。 在每个回合里，它检查最多百分之 bgwriter_lru_percent 的快要被重复使用的缓冲区， 然后写出其中的脏缓冲区。缺省值是 1.0 （这是全部共享缓冲区的百分比）。 这个选项只能在服务器启动的时候或者在 postgresql.conf 文件里设置。
在每个回合里，不超过这么多个缓冲区将做为扫描到的即将重复使用的缓冲区写入磁盘。 缺省值是 5。 这个选项只能在服务器启动的时候或者在 postgresql.conf 文件里设置。
为了减少检查点时刻需要做的工作，后端写进程还会对整个缓冲池进行循环扫描， 把那些认为是脏的缓冲区写出到磁盘。 在每个回合里，它为此检查最多百分之 bgwriter_all_percent 的缓冲区进行操作。 缺省值是 0.333 （这是全部共享缓冲区的百分比）。使用缺省的 bgwriter_delay， 这个设置可以做到每分钟扫描一次整个共享缓冲池。 这个选项只能在服务器启动的时候或者在 postgresql.conf 文件里设置。
在每个回合里，不超过这个数值的缓冲区，将作为扫描整个缓冲池的结果，写入磁盘。 （如果达到这个限制，扫描停止，然后在下个回合里，从下一个缓冲区开始。） 缺省值是 5。 这个选项只能在服务器启动的时候或者在 postgresql.conf 文件里设置。
小的 bgwriter_all_percent 和 bgwriter_all_maxpages 减少后端写进程导致的额外 I/O 负荷， 但是会导致在检查点的时候的更多工作。要降低检查点时的峰值负荷，增加这两个值。 类似的，小的 bgwriter_lru_percent 和 bgwriter_lru_maxpages 减小后端写进程导致的额外的 I/O 负载， 但是会有可能是服务器进程不得不自己发出写动作，降低交互查询的交互性。 要想完全关闭后台写进程，可以把两个 percent 和/或两个 maxpages 设置为零。