effective_io_concurrency (integer)
设置TeleDB可以同时被执行的并发磁盘 I/O 操作的数量。调高这个值,可以增加任何单个数据库会话试图并行发起的 I/O 操作的数目。允许的范围是 1 到 1000,或 0 表示禁用异步 I/O 请求。当前这个设置仅影响位图堆扫描。对于磁盘驱动器,这个设置的一个很好的出发点是组成一个被用于该数据库的 RAID 0 条带或 RAID 1 镜像的独立驱动器数量(对 RAID 5 而言,校验驱动器不计入)。 但是,如果数据库经常忙于在并发会话中发出的多个查询,较低的值可能足以使磁盘阵列繁忙。比保持磁盘繁忙所需的值更高的值只会造成额外的 CPU 开销。SSD 以及其他基于内存的存储常常能处理很多并发请求, 因此它们的最佳值可能是数百。异步 I/O 依赖于一个有效的posix_fadvise函数 (一些操作系统可能没有)。 如果不存在这个函数,将这个参数设置为除 0 之外的任何东西将导致错误。在一些操作系统上(如Solaris) 虽然提供了这个函数,但它不会做任何事情。支持的系统上缺省为1,否则为0。对于一个特定表空间中的表,可以通过设定该表空间的同名参数(见ALTER TABLESPACE) 可以覆盖这个值。
max_worker_processes (integer)
设置系统能够支持的后台进程的最大数量。这个参数只能在服务器启动时设置。默认值为8。在运行一个后备服务器时,你必须把这个参数设置为等于或者高于主控服务器上的值。否则, 后备服务器上可能不会允许查询。修改此值时,也要考虑调整 max_parallel_workers和 max_parallel_workers_per_gather。
max_parallel_workers_per_gather (integer)
设置单个Gather或Gather Merge节点能够开始的工作者的最大数量。 并行工作者会从max_worker_processes建立的进程池中取得, 受限于max_parallel_workers。 注意所要求的工作者数量在运行时可能实际无法被满足。如果这种事情发生, 该计划将会以比预期更少的工作者运行,这可能会不太高效。默认值是2。 把这个值设置为 0将会禁用并行查询执行。注意并行查询可能消耗比非并行查询更多的资源,因为每一个工作者进程时一个完全独立的进程,它对系统产生的影响大致和一个额外的用户会话相同。在为这个设置选择值时, 以及配置其他控制资源利用的设置(例如work_mem)时,应该把这个因素考虑在内。work_mem 之类的资源限制会被独立地应用于每一个工作者,这意味着所有进程的总资源利用可能会比单个进程时高得多。例如,一个使用 4 个工作者的并行查询使用的 CPU 时间、内存、I/O 带宽可能是不使用工作者时的 5 倍之多。
max_parallel_workers (integer)
设置系统支持并行查询的最大工作数。默认值为8。在增加或减少此值时,还应考虑调整max_parallel_workers_per_gather。此外,请注意,此值高于max_worker_processes 的设置将不起作用,因为并行工作进程将从该设置建立的工作进程池中获取。
backend_flush_after (integer)
只要一个后端写入了超过backend_flush_after字节,就会尝试强制 OS 把这些写发送到底层存储。 这样做将会限制内核页高速缓存中的脏数据数量,降低在检查点末尾发出fsync时或者 OS 在后台大批写回数据时卡住的可能性。这常常会导致极大降低的事务延迟,但是也有一些情况中(特别是负载超过shared_buffers但低于 OS 的页面高速缓存时),性能可能会下降。这个设置可能在某些平台上没有效果。合法的范围位于0 (禁用强制写回)和2MB之间。默认是0,即没有强制写回。(如果BLCKSZ不是8kB,最大值将按比例缩放。)
old_snapshot_threshold (integer)
设置在使用快照时,一个快照可以被使用而没有发生snapshot too old 错误风险的最小时间。这个参数只能在服务器启动时设置。如果超过该阈值,旧数据将被清理掉。这可以有助于阻止长时间使用的快照造成的快照膨胀。 为了阻止由于本来对该快照可见的数据被清理导致的不正确结果, 当快照比这个阈值更旧并且该快照被用来读取一个该快照建立以来被修改过的页面时, 将会产生一个错误。值为-1会禁用这个特性,并且这个值是默认值。 对于生产工作有用的值可能从几个小时到几天。该设置将被转换成分钟粒度, 并且小数字(例如0或者1min) 被允许只是因为它们有时对于测试有用。虽然允许高达60d的设置, 但是请注意很多负载情况下,很短的时间帧里就可能发生极大的膨胀或者事务 ID 回卷。当这个特性被启用时,关系末尾的被清出的空间不能被释放给操作系统, 因为那可能会移除用于检测snapshot too old情况所需的信息。 所有分配给关系的空间还将与该关系关联在一起便于重用, 除非它们被显式地释放(例如,用VACUUM FULL)。这个设置不会尝试保证在任何特殊情况下都会生成错误。事实上,如果(例如) 可以从一个已经物化了一个结果集的游标中生成正确的结果, 即便被引用表中的底层行已经被清理掉也不会生成错误。 某些表不能被过早地安全清除,并且因此将不受这个设置的影响, 比如系统目录。对于这些表, 这个设置将不能降低膨胀,也不能降低在扫描时产生 snapshot too old错误的可能性。