postgreSQL重要配置文件及参数设置

postgreSQL重要配置文件及参数设置

目录

pg_hba.conf

作用：

  • 哪些主机可以连接数据库实例
  • 哪个数据库用户可以使用它
  • 允许这个用户使用哪些数据库
  • 客户端使用什么连接方式和认证方式
# TYPE      DATABASE        USER            ADDRESS                 METHOD


其中TYPE
local ：local匹配使用Unix域套接字的连接
host  ：匹配使用 TCP/IP建立的连接，同时匹配SSL和非SSL连接
       启用远程连接需要修改postgresql.conf中的listen_addresses参数

METHOD
- trust
无条件地允许连接。
允许任何可以与PostgreSQL数据库服务器连接的用户身份登入
不需要口令或者其他任何认证。

- reject
无条件拒绝连接。常用于从一个组中“过滤出”特定主机
例如一个reject行可以阻塞特定的主机连接,而后面一行允许特定网络中的其余主机进行连接

- md5和password口令认证

postgresql.conf

listen_addresses = '*'	#（关联配置文件pg_hba.conf）
#指定服务器在哪些 TCP/IP 地址上监听客户端连接。
值的形式是一个逗号分隔的主机名和/或数字 IP 地址列表。	
特殊项*对应监听所有可用 IP 接口
0.0.0.0允许监听所有 IPv4 地址
并且::允许监听所有 IPv6 地址
如果列表为空，服务器将根本不会监听任何 IP 接口，在这种情况中只能使用 Unix 域套接字来连接它。
默认值是localhost，它只允许建立本地 TCP/IP "环回"连接。
这能帮助在不安全网络接口上阻止重复的恶意连接请求。
这个参数只能在服务器启动时设置。 

port = 5866
#服务器监听的 TCP 端口；默认是 5866 。

max_connections = 100
#决定数据库的最大并发连接数。
这个参数只能在服务器启动时设置。（cpu 1核 50个链接）

shared_buffers
#它表示数据缓冲区中的数据块的个数，每个数据块的大小是8KB。
数据缓冲区位于数据库的共享内存中，它越大越好，不能小于128KB。
这个参数只有在启动数据库时，才能被设置。
默认值是128MB。
推荐值：1/4 主机物理内存  

wal_buffers 
#用于还未写入磁盘的 WAL 数据的共享内存量。
默认值 -1 表示将该参数值设置为 shared_buffers 的 1/32 的大小 （ 大约 3%），
但是不小于64kB 也不大于一个WAL段的大小（通常为 16MB）。 
如果自动的选择太大或太小可以手工设置该值，但是任何小于 32kB 的正值都将被当作 32kB。 
这个参数只能在服务器启动时设置。
事务日志缓冲区位于数据库的共享内存中。
推荐值：min( 2047MB, shared_buffers/32 ) = 512MB

work_mem
#指定在写到临时磁盘文件之前用于内部排序操作和哈希表的内存量。
ORDER BY， DISTINCT 和合并连接（ merge joins） 都会用到排序操作。 
默认值为 4 兆字节（ 4MB）。
推荐值：work_mem = (输入内存数量- shared_buffers)/(连接数 * 3）* 1024 (单位是 KB);

maintenance_work_mem
#它决定数据库的维护操作使用的内存空间的大小。
数据库的维护操作包括VACUUM、CREATE INDEX和ALTER TABLE ADD FOREIGN KEY等操作。 
值如果比较大，通常可以缩短VACUUM数据库和从dump文件中恢复数据库需要的时间。
maintenance_work_mem存放在每个数据库进程的私有内存中，而不是存放在数据库的共享内存中。这个参数可以在任何时候被设置。

开启日志采集
logging_collector = on      

日志目录
log_directory = 'log'            

log_filename = 'postgresql-%Y-%m-%d_%H%M%S.log'  日志文件名字
log_truncate_on_rotation = off    是否覆盖
log_rotation_age = 1d             每天生成
log_rotation_size = 10MB          每个日志大小

优化建议

andom_page_cost = 2.5
规划器对一次非顺序获取磁盘页面的代价估计。 默认值是 4.0。 高端存储或者ssd可以适当调小该参数。

autovacuum_max_workers = 10
指定能同时运行的autovacuum进程的最大数量， 适当调大， 避免vacuum不及时导致表膨胀

checkpoint_completion_target = 0.7
增加checkpoint_completion_target来降低检查点的I/O负载， 默认0.5

archive_timeout =1800
强制服务器来周期性地切换到一个新的 WAL 段文件

archive_command = 'test ! -f /paic/dba/pgbackup/${PGNAME}/archlog/%f && pxz -2 < %p >
/paic/dba/pgbackup/${PGNAME}/archlog/%f'
pxz压缩归档日志， 64M的归档， 压缩时间可以在0.5s内， 压缩比一般可在1:3左右

使配置生效的几种方法

使配置生效的几种方法
1）用超级用户运行 	
 SELECT pg_reload_conf(); 
2）使用pg_ctl命令触发SIGHUP信号 
 pg_ctl reload
3）用UNIX的kill手动发起HUP信号
ps -ef|grep -i postmaster|grep -v grep|xargs kill -HUP	 
4）重启数据库服务

查看配置

show all;                       #查看所有数据库参数的值
show shared_buffers;            #查看某个参数的当前值(可查看当前会话值)
select current_setting('shared_buffers');

配置生效级别

sihup
给服务器发送HUP信号会使服务器重新加载postgresql.conf配置，可以立即生效

postmaster
只有服务重启才能生效

internal
编译期间的设置，只有重新编译才能生效。

backend
与sighup类似，但是不影响正在运行的会话，只在新会话中生效

superuser
使用superuser(如postgres)才能更改，不用重新加载所有配置即可生效

user
单个会话用户可以在任意时间做修改，只会影响该会话

配置全局参数
全局参数修改，调用pg_reload_conf()生效，参数修改写入了 postgresql.auto.conf

配置session级别参数
当前session有效，reset恢复

配置库级别参数
不写入postgresql.auto.conf

alter database mydb set work_mem='16MB';
select * from pg_db_role_setting where setdatabase in (select oid from pg_database where datname in ('mydb')) ;

配置role级别参数
不写入postgresql.auto.conf

alter role user_t set work_mem='2MB';
select * from pg_db_role_setting where setrole in (select usesysid from pg_user where usename in ('user_t'))
order by setrole,setdatabase;

查看当前的参数设置
库和role级别没有影响全局参数的值

select name,setting,source from pg_settings where name='work_mem';

postmaster级别需要重启才能生效
调用pg_reload_conf()生效，参数修改写入了 postgresql.auto.conf，但是并没有生效，postmaster需要重启数据库才能生效

数据库配置优化

workd_mem(整数)

为每个进程单独分配的内存，主要用于排序、hash等操作

  • 描述：用于设置内部排序操作和 Hash 表在开始写入临时磁盘文件之前可以使用的内存大小。
  • 默认值：4MB，但可以根据工作负载和可用内存进行调整。修改后需要重启数据库。修改 work_mem 后，新的内存设置会立即应用于接下来的查询，而无需重启数据库。
  • 作用：
    • work_mem 参数决定了 PostgreSQL 在执行需要排序或哈希操作的查询时，为每个操作分配的内存量。所有多个并行时总内存会是work_mem的数倍
    • 合适的 work_mem 值可以确保这些操作在内存中完成，避免与磁盘进行频繁的交换（swap），从而提高查询性能。
  • 取值建议：
    • 对于串行无并发的复杂查询场景（平均每个查询有5-10个关联操作），建议将 work_mem 设置为系统总内存的 50% 除以 10。例如，如果系统有 8GB 内存，则 work_mem 可以设置为 400MB。
    • 对于串行无并发的简单查询场景（平均每个查询有2-5个关联操作），建议将 work_mem 设置为系统总内存的 50% 除以 5。
    • 对于并发场景，建议将 work_mem 设置为串行场景下的 work_mem 值除以物理并发数。
  • 示例值：work_mem = 64MB 通常是一个相对较小的值，以避免过度使用内存

maintence_work_mem

也是为每个进程单独分配内存，但是主要用于维护操作，比如vacuum

参数优先级别：

事务级别>会话级别>命令级别>文件级别

PostgreSQL应该调整的参数

1.资源消耗参数

max_connections

允许的最大客户端连接数。这个参数设置大小和work_mem有一些关系。配置的越高，可能会占用系统更多的内存。通常可以设置数百个连接，如果要使用上千个连接，建议配置连接池来减少开销。

shared_buffers(integer)

共享缓存去的大小，相当于ORACLE数据库中的SGA

因为要在多个进程中共享，所以必须使用共享内存技术来存放，一般推荐内存的1/4,不要超过总内存的1/2

PostgreSQL使用自己的缓冲区，也使用Linux操作系统内核缓冲OS Cache。这就说明数据两次存储在内存中，首先是PostgreSQL缓冲区，然后是操作系统内核缓冲区。与其他数据库不同，PostgreSQL不提供直接IO，所以这又被称为双缓冲。PostgreSQL缓冲区称为shared_buffer，建议设置为物理内存的1/4。而实际配置取决于硬件配置和工作负载，如果你的内存很大，而你又想多缓冲一些数据到内存中，可以继续调大shared_buffer
参数-share_buffer

  • 描述：PostgreSQL使用的共享内存缓冲区的大小，用于缓存数据。
  • 默认值：通常为现代系统上设置为系统总内存的25%左右（但不要超过40%）。为了能把对写大量新的或改变的数据的处理分布在一个较长的时间段内，shared_buffers更大的设置通常要求对max_wal_size也做相应增加。修改 shared_buffers 后，需要重启数据库才能应用新的内存配置，以确保新的缓存设置生效。
  • 示例值：shared_buffers = 1GB ， 查询设置的值可以用 show shared_buffers 命令查看
  • 监控和调整：使用工具如 pg_stat_activity、pg_stat_database，以及操作系统的监控工具（如 top、htop）来观察内存使用情况。
  • 查看缓冲区命中率（cache hit ratio），理想情况下应该在 99% 以上。可以通过以下查询查看
SELECT 
    sum(blks_hit) / (sum(blks_hit) + sum(blks_read)) AS cache_hit_ratio 
FROM 
    pg_stat_database;

如果发现缓冲区命中率较低或系统内存使用率不均衡，考虑调整 shared_buffers 并再次测试。

Double Buffering问题

shared_buffers，即共享缓存区的大小，因为要在多个进程中共享，所以必须使用共享内存技术来存放。PostgreSQL的数据文件都在文件系统中，操作系统的文件系统也有缓存，这有可能会导致数据库的数据块除了在PostgreSQL的共享内存中有一个副本以外，在文件系统的缓存中也有一个副本，因此造成内存利用率不高，这就是PostgreSQL中的Double Buffering问题。

  • 在Oracle数据库中，通过设置Direct I/O来避免双缓存问题
  • 但PostgreSQL中未实现对Direct I/O的支持。

为了减少双缓存问题带来的影响，通常使用以下方法解决：

  • 设置较小的shared buffer，将大多数内存给文件系统缓存使用，如在一台有24GB内存的机器上，可以把PostgreSQL中的shared buffer设置为较小值，如500MB～1GB，其他内存都留给文件系统缓存使用。
  • 所以一般来说，shared buffer的设置值不应超过总内存的1/4，如一台256GB的机器，通常把shared buffer设置为32GB就够了。

Effective_cache_size

这个参数主要用于Postgre查询优化器。是单个查询可用的磁盘高速缓存的有效大小的一个假设，是一个估算值，它并不占据系统内存。由于优化器需要进行估算成本，较高的值更有可能使用索引扫描，较低的值则有可能使用顺序扫描。一般这个值设置为内存的1/2是正常保守的设置，设置为内存的3/4是比较推荐的值。通过free命令查看操作系统的统计信息，您可能会更好的估算该值。

[pg@e22 ~]$ free -g
              total        used        free      shared  buff/cache   available
Mem:             62           2           5          16          55          40
Swap:             7           0           7

work_mem

这个参数主要用于写入临时文件之前内部排序操作和散列表使用的内存量，增加work_mem参数将使PostgreSQL可以进行更大的内存排序。这个参数和max_connections有一些关系，假设你设置为30MB，则40个用户同时执行查询排序，很快就会使用1.2GB的实际内存。同时对于复杂查询，可能会运行多个排序和散列操作，例如涉及到8张表进行合并排序，此时就需要8倍的work_mem
如下面案例所示，该环境使用4MB的work_mem，在执行排序操作的时候，使用的Sort Method是external merge Disk

kms=> explain (analyze,buffers) select * from KMS_BUSINESS_HALL_TOTAL  order by buss_query_info;
                                                                       QUERY PLAN                                                                        
---------------------------------------------------------------------------------------------------------------------------------------------------------
 Gather Merge  (cost=262167.99..567195.15 rows=2614336 width=52) (actual time=2782.203..5184.442 rows=3137204 loops=1)
   Workers Planned: 2
   Workers Launched: 2
   Buffers: shared hit=68 read=25939, temp read=28863 written=28947
   ->  Sort  (cost=261167.97..264435.89 rows=1307168 width=52) (actual time=2760.566..3453.783 rows=1045735 loops=3)
         Sort Key: buss_query_info
         Sort Method: external merge  Disk: 50568kB
         Worker 0:  Sort Method: external merge  Disk: 50840kB
         Worker 1:  Sort Method: external merge  Disk: 49944kB
         Buffers: shared hit=68 read=25939, temp read=28863 written=28947
         ->  Parallel Seq Scan on kms_business_hall_total  (cost=0.00..39010.68 rows=1307168 width=52) (actual time=0.547..259.524 rows=1045735 loops=3)
               Buffers: shared read=25939
 Planning Time: 0.540 ms
 Execution Time: 5461.516 ms
(14 rows)

当我们把参数修改成512MB的时候，可以看到Sort Method变成了quicksort Memory，变成了内存排序。

kms=> set work_mem to "512MB";
SET
kms=> explain (analyze,buffers) select * from KMS_BUSINESS_HALL_TOTAL  order by buss_query_info;
                                                                QUERY PLAN                                                                
------------------------------------------------------------------------------------------------------------------------------------------
 Sort  (cost=395831.79..403674.80 rows=3137204 width=52) (actual time=7870.826..8204.794 rows=3137204 loops=1)
   Sort Key: buss_query_info
   Sort Method: quicksort  Memory: 359833kB
   Buffers: shared hit=25939
   ->  Seq Scan on kms_business_hall_total  (cost=0.00..57311.04 rows=3137204 width=52) (actual time=0.019..373.067 rows=3137204 loops=1)
         Buffers: shared hit=25939
 Planning Time: 0.081 ms
 Execution Time: 8419.994 ms
(8 rows)

work_mem参数指定的内存不是总共消耗的内存，也不是一个进程分配内存的最大值，而是SQL中的每个HASH或排序操作都会分配这么多
内存，也就是说，包含HASH和排序操作越多的复杂SQL，分配的内存越多。如果有并发的M个进程，每个进程中有N个HASH操作，则需要分配的内存是M×N×work_mem，所以work_mem不要设置得太大，通常保持默认的4MB就足够了。如果把work_mem设置得太大，如超过256MB，很容易因为瞬间的大并发操作导致Out of Memory问题。

maintenance_work_mem

为每个进程单独分配的内存，主要是进行维护操作时需要的内存，指定维护操作使用的最大内存量，例如（Vacuum、Create Index和Alter Table Add Foreign Key），默认值是64MB。由于通常正常运行的数据库中不会有大量并发的此类操作，可以设置的较大一些，提高清理和创建索引外键的速度。

postgres=# set maintenance_work_mem to "64MB";
SET
Time: 1.971 ms
postgres=# create index idx1_test on test(id);
CREATE INDEX
Time: 7483.621 ms (00:07.484)
postgres=# set maintenance_work_mem to "2GB";
SET
Time: 0.543 ms
postgres=# drop index idx1_test;
DROP INDEX
Time: 133.984 ms
postgres=# create index idx1_test on test(id);
CREATE INDEX
Time: 5661.018 ms (00:05.661)

autovacuum_work_mem：

从PostgreSQL 9.4版本开始新增的参数。在PostgreSQL 9.4之前的版本中，AutoVacuum的每一个worker进程与手动做VACUUM一样，分配的内存大小都是由maintence_work_mem参数控制的，现在分开了，AutoVacuum的worker进程由该参数控制，手动VACUUM时分配的内存大小仍由maintence_work_mem参数控制。
此参数默认设置为“-1”，即与原先的行为是一样的，当把此参数设置为其他值时，可以为AutoVacuum的每个worker进程做VACUUM操作时指定不同的内存值。

可以看到在使用默认的64MB创建索引，速度为7.4秒，而设置为2GB后，创建速度是5.6秒

wal_sync_method

每次发生事务后，PostgreSQL会强制将提交写到WAL日志的方式。可以使用pg_test_fsync命令在你的操作系统上进行测试，fdatasync是Linux上的默认方法。
如下所示，我的环境测试下来fdatasync还是速度可以的。不支持的方法像fsync_writethrough直接显示n/a。

postgres=# show wal_sync_method ;
 wal_sync_method 
-----------------
 fdatasync
(1 row)

[pg@e22 ~]$ pg_test_fsync -s 3
3 seconds per test
O_DIRECT supported on this platform for open_datasync and open_sync.

Compare file sync methods using one 8kB write:
(in wal_sync_method preference order, except fdatasync is Linux's default)
        open_datasync                      4782.871 ops/sec     209 usecs/op
        fdatasync                          4935.556 ops/sec     203 usecs/op
        fsync                              3781.254 ops/sec     264 usecs/op
        fsync_writethrough                              n/a
        open_sync                          3850.219 ops/sec     260 usecs/op

Compare file sync methods using two 8kB writes:
(in wal_sync_method preference order, except fdatasync is Linux's default)
        open_datasync                      2469.646 ops/sec     405 usecs/op
        fdatasync                          4412.266 ops/sec     227 usecs/op
        fsync                              3432.794 ops/sec     291 usecs/op
        fsync_writethrough                              n/a
        open_sync                          1929.221 ops/sec     518 usecs/op

Compare open_sync with different write sizes:
(This is designed to compare the cost of writing 16kB in different write
open_sync sizes.)
         1 * 16kB open_sync write          3159.780 ops/sec     316 usecs/op
         2 *  8kB open_sync writes         1944.723 ops/sec     514 usecs/op
         4 *  4kB open_sync writes          993.173 ops/sec    1007 usecs/op
         8 *  2kB open_sync writes          493.396 ops/sec    2027 usecs/op
        16 *  1kB open_sync writes          249.762 ops/sec    4004 usecs/op

Test if fsync on non-write file descriptor is honored:
(If the times are similar, fsync() can sync data written on a different
descriptor.)
        write, fsync, close                3719.973 ops/sec     269 usecs/op
        write, close, fsync                3651.820 ops/sec     274 usecs/op

Non-sync'ed 8kB writes:
        write                            400577.329 ops/sec       2 usecs/op

wal_buffers

事务日志缓冲区的大小，PostgreSQL将WAL记录写入缓冲区，然后再将缓冲区刷新到磁盘。在PostgreSQL 12版中，默认值为-1，也就是选择等于shared_buffers的1/32（大约3%），但是不小于64KB也不大于WAL文件的尺寸（通常为16MB），不应该超过WAL文件的大小，通常保持默认值就可以了，如果手动设置，一般为4MB～16MB 。如果自动的选择太大或太小可以手工设置该值。
建议：一般考虑设置为16MB

synchronous_commit

客户端执行提交，并且等待WAL写入磁盘之后，然后再将成功状态返回给客户端。可以设置为on，remote_apply，remote_write，local，off等值。默认设置为on。如果设置为off，会关闭sync_commit，客户端提交之后就立马返回，不用等记录刷新到磁盘。此时如果PostgreSQL实例崩溃，则最后几个异步提交将会丢失。

default_statistics_target

PostgreSQL使用统计信息来生成执行计划。统计信息可以通过手动Analyze命令或者是autovacuum进程启动的自动分析来收集，default_statistics_target
参数指定在收集和记录这些统计信息时的详细程度。默认值为100对于大多数工作负载是比较合理的，对于非常简单的查询，较小的值可能会有用，而对于复杂的查询（尤其是针对大型表的查询），较大的值可能会更好。为了不要一刀切TA，可以使用ALTER BLE .. ALTER COLUMN .. SET STATISTICS覆盖特定表列的默认收集统计信息的详细程度。

checkpoint_timeout、max_wal_size，min_wal_size、checkpoint_completion_target

了解这两个参数以前，首先我们来看一下，触发检查点的几个操作。

  • 直接执行checkpoint命令
  • 执行需要检查点的命令（例如pg_start_backup,Create database,pg_ctl stop/start等等）
  • 自上一个检查点以来，达到了已经配置的时间量（checkpoint_timeout ）
  • 自上一个检查点以来生成的WAL数量（max_wal_size）

使用默认值，检查点将在checkpoint_timeout=5min。也就是每5分钟触发一次。而max_wal_size设置是自动检查点之间增长的最大预写日志记录（WAL）量。默认是1GB，如果超过了1GB，则会发生检查点。这是一个软限制。在一个特殊的情况下，比如系统遭遇到短时间的高负载，日志产生几秒种就可以达到1GB，这个速度已经明显超过了checkpoint_timeout ，pg_wal目录的大小会急剧增加。此时我们可以从日志中看到相关类似的警告。

LOG:  checkpoints are occurring too frequently (9 seconds apart)
HINT:  Consider increasing the configuration parameter "max_wal_size".
LOG:  checkpoints are occurring too frequently (2 seconds apart)
HINT:  Consider increasing the configuration parameter "max_wal_size".

所以要合理配置max_wal_size，以避免频繁的进行检查点。一般推荐设置为16GB以上，不过具体设置多大还需要和工作负荷相匹配。

min_wal_size参数是只要 WAL 磁盘使用量保持在这个设置之下，在做检查点时，旧的 WAL 文件总是被回收以便未来使用，而不是直接被删除。

而检查点的写入不是全部立马完成的，PostgreSQL会将一次检查点的所有操作分散到一段时间内。这段时间由参数checkpoint_completion_target
控制，它是一个分数，默认为0.5。也就是在两次检查点之间的0.5比例完成写盘操作。如果设置的很小，则检查点进程就会更加迅速的写盘，设置的很大，则就会比较慢。一般推荐设置为0.9，让检查点的写入分散一点。但是缺点就是出现故障的时候，影响恢复的时间。
https://pgtune.leopard.in.ua/

max_prepared_transactions

  • 描述：设置可以同时处于“准备”状态的最大事务数。将此参数设置为零（默认值）将禁用 prepared-transaction 功能。此参数只能在服务器启动时设置。
  • 说明：如果您不打算使用已准备的事务，则应将此参数设置为零，以防止意外创建已准备的事务。如果您使用的是已准备好的事务，您可能希望max_prepared_transactions至少与max_connections一样大，以便每个会话都可以有一个准备好的事务挂起。

hash_mem_multiplier(浮点)

  • 描述：用于计算基于哈希的操作可以使用的最大内存量。 最终限制通过将work_mem乘以hash_mem_multiplier来决定。 默认值为 1.0，这使得基于hash的操作与基于排序的操作一样，都取决于简单的work_mem最大值。
  • 推荐值：在查询操作经常发生溢出的环境中，请考虑增加内存压力，尤其是当简单地增加内存压力时（内存压力通常表现为间歇性内存不足错误）。默认设置 2.0 通常适用于混合工作负载。2.0 - 8.0 或更高范围内的更高设置在已增加到 40MB 或更大的环境中可能有效

maintenance_work_mem(integer)

  • 描述：用于VACUUM、ANALYZE、CREATE INDEX等维护操作能使用的最大内存量。
  • 默认值：64MB。
  • 示例值：maintenance_work_mem = 512MB
  • 注意：对于死亡元组标识的集合，VACUUM最多只能使用1GB的内存。当 autovacuum 运行时，最多可以分配 autovacuum_max_workers 次此内存，因此请注意不要将默认值设置得太高。通过单独设置autovacuum_work_mem来控制这一点可能很有用。

autovacuum_work_mem (integer)

  • 描述：指定每个自动清理工作者进程能使用的最大内存量。 如果指定值时没有单位，则以千字节为单位。
  • 默认值：-1 表示转而使用 maintenance_work_mem的值。
  • 注意：对于死亡元组标识的集合，autovacuum最大只能使用1GB内存，所以设置autovacuum_work_mem到一个更高的值，对于autovacuum在扫描表时所能收集的死亡元组数量是无效的。

huge_pages(enum)

  • 描述：控制是否为主共享内存区域请求da页。
  • 默认值：try。如果huge_pages被设置为try，则服务器将尝试请求大页，但是如果失败会退回到默认的方式。如果为on，请求大页失败将使得服务器无法启动。如果为off，则不会请求大页。
  • 注意：目前，此设置仅在 Linux 和 Windows 上受支持。当设置为 try 时，该设置在其他系统上将被忽略。在 Linux 上，仅当 shared_memory_type 设置为 mmap（默认值）时才受支持。大页面的使用会导致更小的页面表以及花费在内存管理上的 CPU 时间更少，从而提高性能

如果操作系统未开启大页或分配的大页内存太小，数据库虽仍然能启动，但不再使用大页内存。

huge_page_size (integer)

  • 描述：控制大页的大小，当他们通过huge_pages启用大页面时。 默认为零 (0)。 当设置为0时，将使用系统默认的大页大小。 这个参数只能在服务器启动时设置。
  • 默认值：0。目前仅在 Linux 上支持非默认设置。

shared_memory_type (enum)

  • 描述：指定服务器应用于主共享内存区域的共享内存实现，包括 PostgreSQL 的共享缓冲区和其他共享数据。 可能的值为 mmap (对使用 mmap 分配的匿名共享内存)，sysv (通过 shmget 分配的系统V 共享内存)，和windows (Windows共享内存)。
    注意：sysv 选项不是任何平台的默认选项，通常不建议使用，因为它通常需要非默认的内核设置来允许大量的地址分配

dynamic_shared_memory_type(enum)

  • 描述：用于指定PostgreSQL使用的动态共享内存（Dynamic Shared Memory, DSM）的实现类型。
  • 默认值：posix(适用于大多数类Unix系统（如Linux和BSD）)
  • 可选值：sysv、windows、mmap

min_dynamic_shared_memory (integer)

描述：指定在服务器启动时将要分配给并行查询使用的内存容量。 当此内存区域不够用或被并发查询耗尽时，新的并行查询尝试使用dynamic_shared_memory_type配置的方法从操作系统临时分配额外的共享内存，由于内存管理开销该方法可能慢一些。

  • 默认值： 默认值是0(无)。

temp_buffers(integer)

  • 描述：为每个数据库会话设置用于临时缓冲区的最大内存.这些是仅用于访问临时表的会话本地缓冲。
  • 默认值：8MB。通常是一个相对较小的值。更改 temp_buffers 后，新的缓冲区设置会立即应用于会话的临时操作，而无需重启数据库。
  • 推荐设置
    - 轻度使用：如果你的应用程序很少使用临时表，默认值可能已经足够。
    - 频繁使用：如果你的应用程序经常使用临时表并且涉及大量数据处理，可以考虑增加 temp_buffers 的值。例如，调整到 32MB 或 64MB。

logical_decoding_work_mem (integer)

描述:指定逻辑解码要使用的最大内存量，在将某些解码的更改写入本地磁盘之前。 这将限制逻辑流复制连接使用的内存量。它默认为 64 兆字节（64MB）。
注意：由于每个复制连接仅使用此大小的单个缓冲区，并且安装通常不会同时具有多个此类连接（受 max_wal_senders 的限制），因此将此值设置得明显高于 work_mem是安全的，从而减少写入磁盘的解码更改数量。

max_stack_depth

  • 描述：指定服务器执行堆栈的最大安全深度。此参数的理想设置是内核强制执行的实际堆栈大小限制（由或本地等效设置），减去一兆字节左右的安全裕度。
    -** 默认值**：2MB。保守来说很小，不太可能有崩溃的风险。但是，它可能太小而无法执行复杂的功能。
    注意：在设置 max_stack_depth 时，还需要确认系统的堆栈大小限制。你可以使用 ulimit 命令来查看和调整。确保系统级的堆栈大小足够大以支持你在 max_stack_depth 中配置的值
ulimit -s  # 查看当前堆栈大小
ulimit -s unlimited  # 设置堆栈大小为无限制

2 磁盘相关参数

temp_file_limit (integer)

  • 描述：指定一个进程能用于临时文件（如排序和哈希临时文件，或者用于保持游标的存储文件）的最大磁盘空间量
  • 默认值：-1 （意味着没有限制）。只有超级用户和具有适当 SET 权限的用户才能更改此设置。

3 内核资源使用

max_files_per_process (integer)

  • 描述：每个服务器子进程允许同时打开的最大文件数目。默认是 1000 个文件。
  • 注意：如果很多进程都尝试打开很多文件，内核将允许独立进程打开比个系统真正可以支持的数目大得多得文件数。如果你发现自己看到了“Too many open files”这样的失败，可尝试减小这个设置。这个参数只能在服务器启动时设置。

系统允许的最大内存页面shmmax和内存段shmall配置

从PostgreSQL 9.3版本开始，共享内存已从System V方式变成了使用POSIX方式和mmap方式，因此在PostgreSQL 9.3版本之后不再需要配置Linux的“shmmax”和“shmall”参数，而在此之前的版本中则需要配置这两个参数，它们的含义分别如下

  • ·shmall：表示整个系统内可以为共享内存配置的共享内存页面数。如果一台机器上运行有多个数据库实例，需要把此值设置成大于各个数据库实例所需要的共享内存之和。简单的做法是设置成机器总内存的页面数。

  • ·shmmax：表示单个共享内存段（Shared Memory Segment）可以创建的共享内存的最大值。通常设置成机器的总内存数就可以了。

shmall的单位是页面，而shmmax的单位是字节。
一台256GB的机器的配置如下：

kernel.shmmax = 274877906944
kernel.shmall = 67108864

信号量设置

除设置SysV共享内存的参数外，还需要设置SysV信号量的相关参数，SysV信号量用于对共享内存访问时进行锁管理。Linux下需要配置的信号量参数主要有以下几个。

·SEMMSL：内核参数，控制每个信号集合的最大信号数。
·SEMMNS：内核参数，控制系统范围内能使用的最大信号量数。
·SEMOPM：semop()函数每次调用所能操作的信号量集中信号量的最大值。
·SEMMNI：内核参数，控制整个系统中信号集的最大数量。

上面提到了一个概念——“信号量集”，每个信号量集由很多个信号量组成，操作系统可以对一个信号量集做一个原子操作，所以系统中信号量的最大数目=每个信号量集的大小*信号量集的个数，即：

SEMMNS=SEMMSL* SEMMNI

而SEMOPM是指对某个信号量集进行一个原子操作时可以操作的信号量数，所以其最大值不应超过信号量集中信号量的数目，通常设置为相等，即：

SEMOPM=SEMMS

在PostgreSQL数据库中，这几个参数有如下要求：

·SEMMNI>=ceil((max_connections+autovacuum_max_workers+4)/16)。
·SEMMSL>=17。

从前面的讲解中可以知道：

·SEMOPM <=SEMMSL。
·SEMMNS=SEMMSL×SEMMNI=ceil((max_connections+autovacuum_max_workers+4)/16)×17。

假设一个数据库有如下配置：
·max_connections=2000，但以后有可能超过2000个连接，认为设置到10000是极限，下面按10000来计算信号量的配置。

·autovacuum_max_workers=3。

则这几个参数的配置值如下：

·SEMMNI=ceil((max_connections+autovacuum_max_workers+4)/16)=626，取一个整数650。
·SEMMSL要求大于17，如设置20就可以了。
·SEMOPM与SEMMSL相同，即20。
·SEMMNS=SEMMNI×SEMMSL=650×20=13000。

那么，此数据库在/etc/sysctl.conf中的配置如下：
# SEMMSL SEMMNS SEMOPM SEMMNI
kernel.sem=20 13000 20 650

Oracle数据库也需要设置信号量参数，但设置的值一般比PostgreSQL数据库要大一些，这些参数的值设置得大一些并不会出现明显的资源消耗，所以有些公司为了统一比配项，会按Oracle数据库的要求进行配置，这样配置完成后也可以满足PostgreSQL数据库的运行，如5000个连接的Oracle数据库的要求配置如下：

# SEMMSL SEMMNS SEMOPM SEMMNI
kernel.sem=5010 3256500 5010 650

大页配置hurgepage和透明大页Transparent Hugepage

对一些连接数很大且内存较大的PostgreSQL数据库，强烈建议配置大页。这不仅是因为大页的性能会高一些，也是为了避免页表过大。
操作系统把逻辑地址映射成物理地址时，需要把映射关系也存储到一个内存中，这部分内存就是页表。

4 基于代价的清理延迟

在VACUUM和ANALYZE命令的执行过程中，系统维持着一个内部计数器来跟踪各种被执行的I/O操作的估算开销。当累计的代价达到一个限制（由vacuum_cost_limit指定），执行这些操作的进程将按照vacuum_cost_delay所指定的休眠一小段时间。然后它将重置计数器并继续执行。

vacuum_cost_delay (floating point)

  • 描述：当超出开销限制时进程将要休眠的时间量。如果指定值时没有单位，则以毫秒为单位。 其默认值为0，这将禁用基于代价的清理延迟特性。正值将启用基于代价的清理。
  • 注意：在使用基于代价的清理时，vacuum_cost_delay的合适值通常很小，也许是小于1毫秒。

vacuum_cost_page_hit (integer)

  • 描述：清理一个在共享缓存中找到的缓冲区的估计代价。它表示锁住缓冲池、查找共享哈希表 和扫描页内容的代价。它表示读取已经在共享缓冲区（shared buffers）中的页面（page）的代价，而不需要从磁盘中读取。
  • 默认值：1。

vacuum_cost_page_miss (integer)

  • 描述：清理一个必须从磁盘上读取的缓冲区的代价。 它表示锁住缓冲池、查找共享哈希表、从磁盘读取需要的块以及扫描其内容的代价。这个参数表示当 VACUUM 操作需要读取的页面不在共享缓冲区（shared buffers）中，因此需要从磁盘中读入时的代价。
  • 默认值：2。
  • 设置考量：
    • 如果系统 I/O 性能较好（如使用 SSD），可以考虑适当降低 vacuum_cost_page_miss 的值，以减少 VACUUM 操作对磁盘 I/O 的依赖，提高操作效率。
    • 如果系统 I/O 性能较差或磁盘负载较高，可以考虑适当增加 vacuum_cost_page_miss 的值，以降低 VACUUM 操作对磁盘 I/O 的影响，避免过度消耗系统资源。

vacuum_cost_page_dirty(integer)

  • 描述：当清理修改一个之前干净的块时需要花费的估计代价。它表示再次把脏块刷出到磁盘所需要的额外I/O。
    它表示当 VACUUM 操作在某个页面中发现不活动元组（dead tuples）并需要修改该页面（即将其标记为“dirty”，意味着需要额外的 I/O 操作来将脏块写回磁盘）时的代价。
  • 默认值：20 。vacuum_cost_page_dirty 定义了 VACUUM 操作中，当需要修改（或“脏化”）一个页面以清理不活动元组时的“成本”。由于这种修改通常需要额外的磁盘 I/O 操作来将脏块写回磁盘，因此其成本通常设置得比 vacuum_cost_page_hit 和 vacuum_cost_page_miss 高
  • 调整建议：
    • 在大多数情况下，不需要直接修改 vacuum_cost_page_dirty 的默认值。但如果你发现 VACUUM 操作在清理不活动元组时产生了过多的磁盘 I/O，或者系统 I/O 性能较差，你可能需要调整这个参数。
    • 增加 vacuum_cost_page_dirty 的值可以降低 VACUUM 操作清理不活动元组时的“积极性”，从而减少磁盘 I/O。但请注意，这可能会使数据库中的不活动元组积累得更多，从而影响数据库的性能。
    • 减少 vacuum_cost_page_dirty 的值可以增加 VACUUM 操作清理不活动元组的“积极性”，从而减少不活动元组的积累。但请注意，这可能会增加磁盘 I/O 的负载，尤其是在系统 I/O 性能较差的情况下。

vacuum_cost_limit (integer)

  • 描述：将导致清理进程休眠的累计代价。
  • 默认值：200。

5 后台写入器

有一个独立的服务器进程，叫做后台写入器，它的功能就是发出写“脏”（新的或修改过的）共享缓冲区的命令。 当干净的共享缓存数量出现不足时，后台写入器写入一些脏缓存到文件系统，并标记为干净。 不过，后台写入器确实会增加 I/O 的总负荷，因为虽然在每个检查点间隔中一个重复弄脏的页面可能只会写出一次，但在同一个间隔中后台写入器可能会把它写出好几次。

bgwriter_delay(integer)

  • 描述：此参数定义了后台写入器在两次后台写入操作之间的延迟时间。较短的延迟值可能导致更多的I/O操作，但可以减少脏数据在内存中的停留时间。
  • 默认值：通常为200ms。
  • 示例：bgwriter_delay = 10ms表示后台写入器将在每次写入操作后等待10毫秒。

bgwriter_lru_maxpages(integer)

  • 描述：此参数定义了每个轮次中后台写入器可以写出的最大缓冲区页面数量。
  • 默认值：通常为100。
  • 示例：bgwriter_lru_maxpages = 200表示每个轮次中，后台写入器可以写出最多200个脏缓冲区。

bgwriter_lru_multiplier(floating point)

  • 描述：用于控制后台写入器（BgWriter）在每次迭代中写入磁盘的脏数据块量。这个值是一个乘法因子，用于基于最近几轮中服务器进程需要的新缓存页的数量的预估值，来决定每轮中写出的脏页的数量
  • 默认值：通常为2.0。
  • 协同：bgwriter_lru_multiplier 的值需要与 bgwriter_lru_maxpages 协同设置。bgwriter_lru_maxpages 定义了每次后台写入器迭代时写出的最大页面数量，而 bgwriter_lru_multiplier 则决定了在这些页面中应该有多少是脏页。
  • 示例：bgwriter_lru_multiplier = 1.5表示使用较低的乘数来估算下一轮次中将会需要的缓冲区数目

bgwriter_flush_after (integer)

  • 描述：每当后台编写器写入的数据量超过此量时，请尝试强制操作系统向底层存储发出这些写入。这样做将限制内核页面缓存中的脏数据量，从而减少在检查点结束时发出 an 或操作系统在后台以更大批量写回数据时停滞的可能性。通常这将导致事务延迟大大降低，但在某些情况下，尤其是对于大于 shared_buffers 但小于操作系统页面缓存的工作负载，性能可能会下降。此设置可能对某些平台没有影响。如果指定此值时没有单位，则将其视为块，即字节，通常为 8kB。
  • 默认值：512kB。

6. 异步行为

backend_flush_after (integer)

  • 描述：当单个后端写入数据的量超过这个数量时，尝试强制操作系统发送这些写入到底层存储。
  • 默认值：0（表示禁用此功能）单位: KB 。初步可以设置为设备吞吐量的10-20%，例如，如果你的存储设备每秒可以处理100MB的数据，可以将backend_flush_after设置为10MB（10240KB）。
  • 硬件配置:
    • 磁盘类型：如果使用SSD，可能希望设置一个较高的值，因为SSD的写入延迟较低，随机写入性能较好；而对于HDD，可能需要较低的值以避免过多的数据积累导致突发的刷盘操作。
    • 内存大小：系统内存较大时，可以设置一个较高的值，因为可以缓存更多的数据；内存较小时需要更频繁地刷盘以释放内存。
  • 调整：
    • 使用PostgreSQL自带的监控工具如pg_stat_bgwriter查看后台写入统计信息。
    • 观察系统的I/O性能和数据库延迟，逐步调整backend_flush_after值，直到找到最佳平衡点。

effective_io_concurrency (integer)

  • 描述：设置PostgreSQL可以同时被执行的并发磁盘 I/O 操作的数量。调高这个值，可以增加任何单个PostgreSQL会话试图并行发起的 I/O 操作的数目。
  • 默认值：允许的范围是 1 到 1000，或 0 表示禁用异步 I/O 请求。当前这个设置仅影响位图堆扫描。
  • 调整依据：
  • 存储设备类型:
    • SSD（固态硬盘）：SSD的随机读写性能远优于传统HDD，因此可以考虑设置较高的effective_io_concurrency值。
    • HDD（机械硬盘）：对于HDD，由于随机读写性能较差，设置过高可能反而降低性能，所以应设置较低的值。
  • 存储子系统架构:
    • RAID阵列：在RAID 0、RAID 10等配置下，由于并行I/O性能提升，可以设置一个较高的值。
    • SAN/NAS：网络存储设备的I/O性能取决于网络和存储设备的整体能力，需要根据具体情况调整。
  • 工作负载特征:
    • I/O密集型工作负载：对于大量随机读写操作的工作负载，提高effective_io_concurrency有助于改善性能。
    • CPU密集型工作负载：主要消耗CPU资源的任务可能对该参数敏感度较低。
  • 系统内存大小:
    • 较大的系统内存可以更好地缓存数据，减少实际I/O操作次数，因此可以稍微提高effective_io_concurrency值以利用系统的并行I/O能力。

maintenance_io_concurrency(integer)

  • 描述：与 effective_io_concurrency类似，但用于代表许多客户端会话完成的维护工作。
  • 默认值：在受支持的系统上，默认值为 10，否则为 0。通过设置同名的 tablespace 参数，可以覆盖特定表空间中的表的此值

max_worker_processes (integer)

  • 描述：设置系统能够支持的后台进程的最大数量。这个参数只能在服务器启动时设置。
  • 默认值：默认值为 8。
  • 注意：运行一个后备服务器时，你必须把这个参数设置为等于或者高于主控服务器上的值。 否则，后备服务器上可能不会允许查询.
  • 调整建议：如果服务器有足够的CPU和内存资源，并且并发需求较高，可以考虑将max_worker_processes设置为CPU核心数的50%到80%之间（取决于具体的工作负载和其他系统进程的需求

max_parallel_workers_per_gather(integer)

  • 描述：设置单个节点或节点可以启动的最大工作线程数。并行工作线程取自 max_worker_processes 建立的流程池，受max_parallel_workers限制。请注意，请求的工作线程数在运行时实际上可能不可用。如果发生这种情况，该计划的运行工作人员将少于预期，这可能效率低下。默认值为 2。将此值设置为 0 将禁用并行查询执行。

  • 注意：与非并行查询相比，并行查询消耗的资源可能要多得多，因为每个工作进程都是一个完全独立的进程，其对系统的影响与附加用户会话大致相同。在为此设置选择值时，以及在配置控制资源利用率的其他设置（如work_mem）时，应考虑到这一点。诸如此类的资源限制单独应用于每个工作人员，这意味着所有流程的总利用率可能比任何单个流程的总利用率高得多。例如，使用 4 个工作线程的并行查询使用的 CPU 时间、内存、I/O 带宽等可能与根本不使用工作线程的查询相比最多 5 倍。

  • 服务器硬件配置:

  • CPU 核心数: 通常建议 max_parallel_workers_per_gather 值不要超过 CPU 总核数的一半，以避免 CPU 资源过度竞争。

  • 内存大小: 并行工作进程会消耗额外内存，因此内存充足时可以增加该值，但要确保不会导致内存不足。

  • 工作负载特征:

  • 并行查询比例: 如果系统中并发查询较多，并且多数查询都能从并行执行中受益，可以适当增加该值。

  • 查询复杂度: 对于复杂的大查询，增加并行工作进程可以显著缩短执行时间，但对于简单查询，可能收益不明显且增加开销。

  • 当前系统负载:

  • 根据系统当前负载情况调整。如果系统已经处于高负载状态，可能需要降低并行度以平衡资源分配。

  • 并行度限制:

  • max_parallel_workers: 控制全局范围内所有并行工作进程的数量，max_parallel_workers_per_gather 的值应小于或等于 max_parallel_workers 的值。

  • max_worker_processes: 系统级别的后台工作进程总数，也影响并行工作进程的可用性。

max_parallel_maintenance_workers（integer)

  • 描述：设置可由单个实用程序命令启动的最大并行工作线程数。目前，支持使用并行工作线程的并行实用程序命令仅在构建 B 树索引时使用，并且没有选项。并行工作线程取自 max_worker_processes 建立的流程池，受max_parallel_workers限制。请注意，请求的工作线程数在运行时实际上可能不可用。如果发生这种情况，公共程序操作的运行工作线程将少于预期。
  • 默认值：默认值为 2。将此值设置为 0 将禁用实用程序命令对并行工作线程的使用。
    用于控制在执行维护任务（如 CREATE INDEX、VACUUM 和 REINDEX）时可以使用的最大并行工作进程数

max_parallel_workers(integer)

  • 描述：设置系统为并行操作所支持的工作者的最大数量。
  • 默认值：默认值为8。 在增加或者减小这个值时，也要考虑对max_parallel_maintenance_workers以及max_parallel_workers_per_gather进行调整。
  • 注意：这个值设置得大于max_worker_processes将不会产生效果，因为并行工作者进程都是从max_worker_processes所建立的工作者进程池中取出来的。

parallel_leader_participation(boolean)

  • 描述：许领导进程在 和 节点下执行查询计划，而不是等待工作进程。
  • 默认值为on 。设置此值可降低工作进程被阻塞的可能性，因为领导者读取元组的速度不够快，但需要领导者进程等待工作进程启动，然后才能生成第一个元组。领导者在多大程度上可以帮助或阻碍绩效取决于计划类型、工作人员数量和查询持续时间。

old_snapshot_threshold(integer)

描述：设置在使用快照时，一个快照可以被使用而没有发生“snapshot too old” 错误的风险的最小时间。超过此阈值时间的死数据将允许被清除。 这可以有助于阻止长时间使用的快照造成的快照膨胀。为了阻止由于本来对该快照可见的数据被清理导致的不正确结果，当快照比这个阈值更旧并且该快照被用来读取一个该快照建立以来被修改过的页面时，将会产生一个错误。

  • 默认值：-1 (默认值) 禁用此功能,实际上将快照的时限设置为无穷大。

7.WAL日志参数

wal配置对性能影响：30.5. WAL配置 (postgres.cn)
wal设置

wal_level (enum)

  • 描述：确定写入WAL的信息量，影响复制和恢复能力。
  • 可选值：
    • minimal：只记录足够用于崩溃恢复的信息。
    • replica：记录足够的信息以支持WAL归档和流复制。
    • logical：记录足够的信息以支持逻辑解码，这是比replica更详细的日志级别。
    • 默认值：replica（对于大多数用途足够）。修改后需要重启数据库生效。
  • 注意：在 9.6 之前的版本中，这个参数也允许值archive和hot_standby。现在仍然接受这些值，但是它们会被映射到replica。

fsync (boolean)

  • 描述：打开这个参数，PostgreSQL服务器将尝试确保更新被物理地写入到磁盘，做法是发出fsync()系统调用或者使用多种等价的方法
  • 默认值：off关闭。虽然关闭fsync常常可以得到性能上的收益，但当发生断电或系统崩溃时可能造成不可恢复的数据损坏。因此，只有在能很容易地从外部数据中重建整个数据库时才建议关闭fsync。

synchronous_commit (enum)

  • 描述：指定数据库服务器返回“success”指示给客户端之前，必须要完成多少WAL处理。 合法的值为remote_apply, on(默认值), remote_write,local, 和 off。
    如果synchronous_standby_names为空，则唯一有意义的设置为on 和 off ； remote_apply，remote_write 和 local都提供与on相同的本地同步级别。 所有非off模式的本地行为都是等待WAL的本地刷新到磁盘。 在 off模式，无需等待，因此在向客户端报告成功和以后保证事务安全防止服务器崩溃之间可能会出现延迟。
  • remote_apply ：提交将等待，直到来自当前同步备用服务器的答复显示他们已收到事务的提交记录并应用了它，以便它变得对备用服务器上的查询可见，并写入备用服务器上的持久存储。
  • on：提交将等待，直到来自于当前同步的后备服务器的回复显示它们已经收到了事务的提交记录并将其刷入了磁盘。 这保证事务将不会被丢失，除非主服务器和所有同步后备都遭受到了数据库存储损坏的问题。
  • remote_write：提交将等待，直到来自当前的同步后备的回复指示它们已经收到了该事务的提交记录并且已经把该记录写到它们的文件系统
  • local：当事务提交时，写入本地磁盘即可，不用关心备机的情况。
  • off：当数据库事务提交时不需要等待本地WAL buffer写入WAL日志，立刻向客户端返回成功。

wal_sync_method (enum)

  • 描述：用来向强制 WAL 更新到磁盘的方法。如果fsync是关闭的，那么这个设置就不相关，因为 WAL 文件更新将根本不会被强制。
  • 可选值：
    • open_datasync（用open()选项O_DSYNC写 WAL 文件）
    • fdatasync（在每次提交时调用fdatasync()）
    • fsync（在每次提交时调用fsync()）
    • fsync_writethrough（在每次提交时调用fsync()，强制任何磁盘写高速缓存的直通写）
    • open_sync（用open()选项O_SYNC写 WAL 文件）

full_page_writes(boolean)

  • 描述：启用此参数后，PostgreSQL 服务器会在检查点后首次修改该页面时将每个磁盘页面的全部内容写入 WAL。这是必需的，因为在操作系统崩溃期间正在进行的页面写入可能仅部分完成，从而导致磁盘上页面包含新旧数据的混合。通常存储在 WAL 中的行级更改数据不足以在崩溃后恢复期间完全还原此类页面。存储整页图像可以保证页面可以正确还原，但代价是增加了必须写入 WAL 的数据量。（由于 WAL 重播始终从检查点开始，因此在检查点之后对每个页面进行第一次更改时执行此操作就足够了。因此，降低整页写入成本的一种方法是增加检查点间隔参数。
  • 默认值：on。
    注意：关闭此参数可加快正常操作速度，但可能会导致系统故障后不可恢复的数据损坏或静默数据损坏。风险类似于关闭 fsync，但较小，并且应仅根据为该参数建议的相同情况将其关闭。关闭此参数不会影响将 WAL 存档用于时间点恢复 （PITR）。

wal_log_hints(boolean)

  • 描述：当此参数为on 时，PostgreSQL 服务器会在检查点后对该页面进行第一次修改期间将每个磁盘页面的全部内容写入 WAL，即使对于所谓的提示位的非关键修改也是如此
  • 注意：如果启用了数据校验和，则提示位更新始终记录 WAL，并忽略此设置。您可以使用此设置来测试如果数据库启用了数据校验和，将发生多少额外的 WAL 日志记录。
  • 默认值：off

wal_compression (enum)

  • 描述：此参数允许使用指定的压缩方法压缩 WAL。启用后，PostgreSQL 服务器会在基础备份中或基础备份期间压缩写入 WAL full_page_writes整页映像。压缩的页面图像将在 WAL 重播期间解压缩。
  • 注意：不同的编译方式支持的方法不一样.改变 wal_compression 设置需要平衡磁盘 I/O 和 CPU 资源之间的关系。
  • 适用场景：
  • 高写入负载系统：在写入负载高且磁盘 I/O 成为瓶颈的系统中，启用 wal_compression 可以有效减轻磁盘压力。
  • 存储资源有限：在存储资源有限的环境中，启用 wal_compression 可以节省存储空间。
  • 默认值：off

wal_init_zero(enum)

  • 描述：默认值on，此选项将导致新的 WAL 文件填充为零。在某些文件系统上，这可确保在我们需要写入 WAL 记录之前分配空间。但是，写入时复制 （COW） 文件系统可能无法从此技术中受益，因此可以选择跳过不必要的工作。如果设置为 off，则在创建文件时仅写入最后一个字节，以便其具有预期的大小。
  • 设置为 on： 在需要高安全性、避免旧数据泄漏的环境中，建议将 wal_init_zero 设置为 on，以确保新的 WAL 文件不包含旧数据的残留。
  • 设置为 off： 在追求性能、并且对旧数据残留不敏感的环境中，可以将 wal_init_zero 设置为 off，以减少写入额外数据的开销。

wal_recycle(boolean)

  • 描述：如果设置为on（默认值），则此选项会通过重命名 WAL 文件来回收它们，从而避免创建新文件。在 COW 文件系统上，创建新文件系统可能会更快，因此可以选择禁用此行为。
  • 默认值：on。

synchronous_standby_names

  • 描述：指定哪些备库应被视为同步备库。这个参数接受一个或多个备库的application_name或网络地址。
  • 格式：一个或多个用逗号分隔的字符串，每个字符串可以是一个备库的application_name或网络地址。
    单台从可表示为 synchronous_standby_names = ‘Standby1’
    通常有ANY和FIRST两种设置多从的方式，如ANY num(…)表示任意num台答复，FIRST num(…)表示优先级前num的机器都答复
  • 注意：当此参数被设置时，synchronous_commit参数的行为会受到影响，以确保在返回客户端成功之前，同步备库也提交了相应的事务

wal_writer_delay(integer)

描述：WAL写入器在每次刷新WAL到磁盘后的延迟时间。
默认值：200ms。
详细解释：这个参数决定了WAL写入器在每次将WAL数据写入磁盘后的休眠时间。这有助于减少磁盘I/O操作，但也可能增加在崩溃时丢失的数据量。

wal_writer_flush_after(integer)

描述：在WAL写入器休眠之前，允许累积的WAL数据量。
默认值：1MB
详细解释：这个参数与wal_writer_delay一起使用，决定了在WAL写入器休眠之前可以累积多少WAL数据。如果达到这个量，WAL写入器将忽略wal_writer_delay并立即将数据写入磁盘。

wal_skip_threshold(integer)

描述：当 is 和 事务在创建或重写永久关系后提交时，此设置确定如何保留新数据。如果数据小于此设置，请将其写入 WAL 日志;否则，请使用受影响文件的 FSYNC。根据存储的属性，如果此类提交会减慢并发事务的速度，则提高或降低此值可能会有所帮助。如果指定此值时不带单位，则以千字节为单位。默认值为 2MB

wal_buffers(integer)

描述：用于还未写入磁盘的 WAL 数据的共享内存量
默认值：-1（基于shared_buffers的1/32，但不小于64kB）
详细解释：这个参数决定了WAL缓冲区的大小，用于缓存WAL数据直到它们被写入磁盘。如果设置为-1，则PostgreSQL将自动选择一个大小。

commit_delay(int)

描述：设置会在启动 WAL 刷新之前添加时间延迟。如果系统负载足够高，以至于其他事务已准备好在给定的时间间隔内提交，则允许通过单个 WAL 刷新提交更多事务，从而提高组提交吞吐量。但是，它也会将延迟增加，最高可达每次 WAL 刷新。由于如果没有其他事务准备好提交，则延迟只会被浪费，因此仅当即将启动刷新时至少有其他事务处于活动状态时，才会执行延迟。此外，如果禁用，则不会执行延迟。如果指定此值时没有单位，则以微秒为单位。
默认值：默认值为零（无延迟）。

commit_siblings(int)

描述：在执行延迟之前需要的最小并发未结事务数。值越大，在延迟间隔内，至少有一个其他事务更有可能准备好提交。
默认值：默认值为 5 个事务。

检查点

checkpoint_segmentscheckpoint_completion_target设为0.9，checkpoint_timeout`为300秒，这样一般checkpoint的间隔能达到1分钟以上。

checkpoint_timeout (integer)

描述：自动 WAL 检查点之间的最长时间。如果指定值时没有单位，则以秒为单位。
默认值：默认是 5 分钟（5min）。合理的范围在 30 秒到 1 天之间。增加这个参数的值会增加崩溃恢复所需的时间。此参数只能在 postgresql.conf 文件或服务器命令行中设置。
注意：更改 checkpoint_timeout 后，需要等待当前检查点完成，并且等待下一个检查点定时任务触发才能应用新的间隔值。
checkpoint_completion_target (floating point)

描述：控制第一个检查点触发之后，在第二个检查点触发之前，必须完成90%的脏数据落盘（当该次checkpoint操作落盘达到checkpoint_completion_target的比例时，即会进入休眠，等待下一次）
默认值： 0.9。此参数只能在 postgresql.conf 文件或服务器命令行中设置。
注意：此参数将把检查点分布在几乎所有可用的时间间隔上，提供公平一致的I/O负载，同时也为检查点完成开销留下了一些时间。 减少此参数是不被推荐的，因为这会导致检查点完成得更快。会造成处于在检查点和下一个计划检查点之间较少IO之后的检查点会有更高的IO比例

checkpoint_flush_after(int)

描述：每当在执行检查点时写入的数据量超过此量时，请尝试强制操作系统向底层存储发出这些写入。这样做将限制内核页面缓存中的脏数据量，从而减少在检查点结束时发出 an 时或操作系统在后台以更大的批次写回数据时停滞的可能性。通常，这将导致事务延迟大大降低，但在某些情况下，尤其是对于大于 shared_buffers 但小于操作系统页面缓存的工作负载，性能可能会下降。此设置可能对某些平台没有影响。如果指定此值时没有单位，则将其视为块，即字节，通常为 8kB。
默认值：256kB。此参数只能在 postgresql.conf 文件或服务器命令行中设置。
checkpoint_warning (integer)

描述：由于填充WAL段文件导致的检查点之间的间隔低于这个参数表示的时间量，那么就向服务器日志写一个消息（它建议增加max_wal_size的值）
默认值： 如果指定值时没有单位，则以秒为单位。默认值是 30 秒（30s）。零则关闭警告。如果checkpoint_timeout低于checkpoint_warning，则不会有警告产生。此参数只能在 postgresql.conf 文件或服务器命令行中设置。

max_wal_size(integer)

描述：在触发检查点之前，WAL可以增长的最大大小。
默认值：通常为1GB。在特殊的情况下 WAL 尺寸可能会超过max_wal_size。此参数只能在 postgresql.conf 文件或服务器命令行中设置。尽管可以动态修改它们的值，但更改后需要等待当前 WAL 日志循环结束才能完全生效，因为 WAL 日志文件的大小不会立即调整。
示例值：max_wal_size = 2GB

min_wal_size(integer)

描述：只要 WAL 磁盘用量保持在这个设置之下，在检查点时旧的 WAL 文件总是 被回收以便未来使用，而不是直接被删除。这可以被用来确保有足够的 WAL 空间被保留来应付 WAL 使用的高峰，例如运行大型的批处理任务。

默认值：通常为80MB。此参数只能在 postgresql.conf 文件或服务器命令行中设置。尽管可以动态修改它们的值，但更改后需要等待当前 WAL 日志循环结束才能完全生效，因为 WAL 日志文件的大小不会立即调整。
示例值：min_wal_size = 800MB
2.3 归档
archive_mode

描述：archive_mode参数用于控制是否启用WAL归档。WAL归档是PostgreSQL中的一种备份和恢复策略，它通过将WAL文件复制到外部位置来实现。
可选值：
off：关闭WAL归档。
on：启用WAL归档，但不允许在恢复模式下进行归档。
always：启用WAL归档，并允许在恢复模式下进行归档。
注意：
当启用WAL归档时，还需要确保wal_level参数不是MINIMAL，因为MINIMAL模式下不会记录所有必要的WAL信息。
archive_command

描述：archive_command参数用于指定在归档模式下，将WAL文件归档到指定位置的命令或脚本。这个命令或脚本负责将WAL文件从pg_wal目录复制到外部位置。

配置示例：archive_command = 'rsync -av %p user@remote_host:/path/to/archive/%f'

在这个示例中，rsync命令用于将WAL文件复制到远程主机的指定路径。%p和%f是占位符，分别表示WAL文件的路径和文件名。

注意：

如果archive_command参数被设置，或者指定的命令有错误，则可能无法真正进行WAL归档。
WAL归档可以提高数据可靠性和容灾能力，因为即使数据库发生故障，也可以通过归档的WAL文件进行恢复。

archive_library(string)

描述：用于存档已完成的 WAL 文件段的库。如果设置为空字符串（默认值），则启用通过 shell 存档，并使用 archive_command。如果同时设置了archive_command 和 archive_library，则会引发错误。否则，将使用指定的共享库进行存档。
archive_timeout

描述：指定了在没有 WAL 流量（或产生的 WAL 流量很少）的情况下，强制进行 WAL 归档的时长。
默认值：0（表示禁用此功能）
取值范围：0 到 1073741823（单位通常为秒，但如果不指定单位，则默认为秒）
注意：
如果设置 archive_timeout 的值太小，可能会导致过多的 WAL 归档操作，从而浪费存储空间。
推荐的 archive_timeout 设置通常是几分钟（例如 600 秒，即 10 分钟），但这取决于具体的业务需求、存储能力和系统性能。
archive_timeout 只有在 archive_mode 被设置为 on 或 always 时才有效。
2.4 归档恢复

restore_command (string)

描述：用于获取 WAL 文件系列的一个已归档段的本地 shell 命令。这个参数是归档恢复所必需的，但是对于流复制是可选的。

示例：

restore_command = 'cp /mnt/server/archivedir/%f "%p"'
restore_command = 'copy "C:\\server\\archivedir\\%f" "%p"'  # Windows

%f会被替换为从归档中获得的文件的名字
%p会被在服务器上的复制目标路径名替换
%r会被包含上一个可用重启点的文件的名字所替换，%r通常只被温备配置所使用
要嵌入一个真正的%字符，需要写成%%

注意：很重要的一点是，该命令只有在成功时才返回一个为零的退出状态。一个例外是如果该命令被一个信号（不是SIGTERM，它是数据库服务器关闭的一部分）或者一个 shell 错误（例如命令未找到）终止，则恢复将会中止并且服务器将不会启动。

archive_cleanup_command (string)

描述：这个可选参数指定了一个 shell 命令，它将在每一个重启点被执行。 archive_cleanup_command的目的是提供一种清除不再被后备服务器需要的旧的已归档 WAL 文件的机制。
示例：archive_cleanup_command = 'pg_archivecleanup /mnt/server/archivedir %r'

recovery_end_command (string)

描述：这个参数指定了一个将只在恢复末尾被执行一次的 shell 命令。这个参数是可选的。 recovery_end_command的目的是为复制或恢复之后的清除提供一种机制。
注意：如果该命令返回一个非零退出状态，则一个警告日志消息将被写出并且不管怎样该数据库将继续启动。 一个例外是如果该命令被一个信号或者 shell 错误（例如命令未找到）中止，该数据库将不会继续启动。
2.5 恢复目标
默认情况下，恢复将会一直恢复到 WAL 日志的末尾。下面的参数可以被用来指定一个更早的停止点。 在recovery_target、recovery_target_lsn、recovery_target_name、recovery_target_time和recovery_target_xid中， 最多只能使用一个，如果在配置文件中使用了多个，将会产生一个错误。这个参数只能在服务器启动时设置。

recovery_target=‘immediate’

描述：这个参数指定恢复应该在达到一个一致状态后尽快结束，即尽早结束。在从一个在线备份中恢复时，这意味着备份结束的那个点。
在技术上，这是一个字符串参数，但是'immediate'是目前唯一允许的值。

recovery_target_name (string)

描述：这个参数指定（pg_create_restore_point()所创建）的已命名的恢复点，恢复将进入该恢复点。

recovery_target_time (timestamp)

描述：此参数指定恢复将执行的时间戳。精确的停止点还受到recovery_target_inclusive得影响。

recovery_target_xid (string)

描述：这个参数指定恢复将进入的事务 ID。记住虽然事务 ID 是在事务开始时顺序分配的，但是事务可能以不同的数字顺序完成。 那些在指定事务之前（也可以包括该事务）提交的事务将被恢复。

recovery_target_lsn (pg_lsn)

描述：此参数指定恢复将继续进行的预写日志位置的LSN。精确的停靠点也受 recovery_target_inclusive的影响。 使用系统数据类型pg_lsn解析此参数。

recovery_target_timeline(string)

描述：指定恢复到特定时间线。该值可以是数字时间线 ID 或特殊值。该值将沿着执行基本备份时的同一时间线恢复。该值将恢复到存档中找到的最新时间线，这在备用服务器中非常有用。
默认值：latest是默认值。
注意：要以十六进制形式指定时间轴 ID

recovery_target_action(enum)

描述：指定服务器在达到恢复目标后应执行的操作。默认值为 pause，这意味着恢复将暂停。 表示恢复过程将完成，服务器将开始接受连接。最后在达到恢复目标后将停止服务器。

注意：该设置的预期用途是允许对数据库执行查询，以检查此恢复目标是否是恢复的最理想点。可以使用（参见表 9.93）恢复暂停状态，这会导致恢复结束。如果此恢复目标不是所需的停止点，请关闭服务器，将恢复目标设置更改为以后的目标，然后重新启动以继续恢复。

参数解释如下
pause：恢复到目标点后，数据库将暂停并等待用户手动干预。这是默认值。
promote：恢复到目标点后，数据库将自动结束恢复并进入正常运行状态。
shutdown：恢复到目标点后，数据库将关闭
适用场景：

时间点恢复（PITR）：你可以在恢复过程中指定一个时间点、事务ID或恢复标记，并控制在恢复到该点后数据库的行为。例如，你可以指定 promote 让数据库自动结束恢复，或者指定 pause 让数据库暂停以便进一步检查。

延迟应用日志（delayed application）：在某些流复制的场景中，你可能希望将恢复目标设定在一定的时间点之后，并在恢复到该点后采取特定的操作。

recovery_target_inclusive(bool)

描述：指定是在指定的恢复目标 （） 之后停止，还是在恢复目标 （） 之前停止。在指定recovery_target_lsn、recovery_target_time或recovery_target_xid时适用。此设置控制恢复中是否包括分别具有目标 WAL 位置 （LSN）、提交时间或事务 ID 的事务。默认值为on

复制

3.1 发送服务器

max_wal_senders

描述： 主要用于流复制，指定了可以同时连接到主节点的最大备节点数量。每个备节点在连接到主节点时，都会占用一个 WAL sender 进程。wal_level必须设置为replica或更高级别以允许来自后备服务器的连接。
默认值：默认值为 10。 0，表示复制被禁用；
注意：
考虑备节点数量：在设置 max_wal_senders 参数时，当运行备用服务器时，你必须将此参数设置为与主服务器上相同的或更高的值。否则，备用服务器中将不允许查询。
考虑主节点性能：增加 max_wal_senders 的值会增加主节点的资源消耗

max_replication_slots (integer)

描述：指定服务器可以支持的复制槽最大数量。默认值为10。这个参数只能在服务器启动时设置。将它设置为一个比当前已有复制槽要少的值会阻碍服务器启动。此外，要允许使用复制槽， wal_level必须被设置为replica或 更高。

wal_keep_size (integer)

描述：指定在后备服务器需要为流复制获取日志段文件的情况下，pg_wal目录下所能保留的过去日志文件段的最小尺寸。
默认值：0,系统将会自动调整其大小。
提问：wal_keep_size=1G，是否当后备服务器未接收的wal大小超过1G才会断开吗？

max_slot_wal_keep_size

描述：指定允许复制槽在检查点时保留在目录中的 WAL 文件的最大大小。如果为 -1（默认值），则复制槽可以保留无限数量的 WAL 文件。否则，如果复制槽的restart_lsn落后于当前 LSN 的大小超过给定大小，则使用该槽的备用数据库可能由于删除了所需的 WAL 文件而无法继续复制。您可以在 pg_replication_slots 中查看复制槽的 WAL 可用性。

wal_sender_timeout (integer)

描述：中断那些停止活动超过这个时间量的复制连接，这对发送服务器检测一个费用服务器崩溃或网络中断有用。
默认值：如果指定值时没有单位，则以毫秒为单位。默认值是 60 秒。值0将禁用超时机制。

track_commit_timestamp (boolean)

描述：记录事务的提交时间。这个参数只能在postgresql.conf 文件中或在服务器命令行上设置。默认值是off。

3.2. 主服务器

synchronous_standby_names (string)

描述：这个参数指定一个支持同步复制的后备服务器的列表。 可能会有一个或者多个活动的同步后备服务器，在这些后备服务器确认收到它们的数据之后，等待提交的事务将被允许继续下去。

vacuum_defer_cleanup_age (integer)

描述：指定VACUUM和HOT更新在清除死亡行版本之前，应该推迟多久（以事务数量计）。
默认值：零个事务
后备服务器上的hot_standby_feedback可以作为使用这个参数的一种替代方案。

3.3. 后备服务器

primary_conninfo (string)

描述：指定备用服务器用来连接发送服务器的连接字符串
示例：primary_conninfo = 'host=192.168.152.134 port=5432 user=replica password=replica'

primary_slot_name (string)

描述：有选择地指定通过流复制连接到发送服务器时使用一个现有的复制槽来控制上游节点上的资源移除。指定复制槽
注意：如果在 WAL 接收器进程运行时更改此参数，则该进程将发出关机信号，并预期使用新设置重新启动（除非primary_conninfo为空字符串）。 如果没有设置primary_conninfo或服务器没有处于备用模式，则此设置无效。

hot_standby (boolean)

描述：指定在恢复期间，你是否能够连接并运行查询。默认值是on。

max_standby_archive_delay

描述：当热备用处于活动状态时，此参数确定备用服务器在取消与即将应用的 WAL 条目冲突的备用查询之前应等待多长时间， 当从 WAL 存档中读取 WAL 数据（因此不是最新的）时适用。如果指定此值时不带单位，则以毫秒为单位。默认值为 30 秒。值为 -1 允许备用数据库永远等待冲突查询完成。

max_standby_streaming_delay

描述：当热备用处于活动状态时，此参数确定备用服务器在取消与即将应用的 WAL 条目冲突的备用查询之前应等待多长时间， 当通过流复制接收 WAL 数据时适用。如果指定此值时不带单位，则以毫秒为单位。默认值为 30 秒。值为 -1 允许备用数据库永远等待冲突查询完成。
注意：这与查询在取消之前可以运行的最长时间不同;相反，它是从主服务器接收 WAL 数据后允许应用 WAL 数据的最大总时间。因此，如果一个查询导致了显著的延迟，则后续冲突查询的宽限时间将大大缩短，直到备用服务器再次赶上。

wal_receiver_create_temp_slot(bool)

描述：指定未配置要使用的永久复制槽时，WAL 接收器进程是否应在远程实例上创建临时复制槽（使用 primary_slot_name）。默认值为关闭。此参数只能在文件或服务器命令行中设置。如果在 WAL 接收器进程运行时更改此参数，则会发出该进程关闭的信号，并预期会使用新设置重新启动。

wal_receiver_status_interval(int)

描述：指定备用数据库上的 WAL 接收器进程的最小频率，以将有关复制进度的信息发送到主备用数据库或上游备用数据库，在主备用数据库或上游备用数据库中可以使用pg_stat_replication视图查看该信息。备用数据库将报告它写入的最后一个预写日志位置、它刷新到磁盘的最后一个位置以及它应用的最后一个位置。此参数的值是报表之间的最大时间量。每次写入或刷新位置更改时都会发送更新，如果设置为非零值，则按此参数指定的频率发送更新。在其他情况下，在忽略此参数的情况下发送更新;例如，当现有 WAL 的处理完成或设置为 时。因此，应用位置可能略微滞后于真实位置。如果指定此值时没有单位，则将其视为秒。
默认值为 10 秒。

hot_standby_feedback(boolean)

描述：指定热备用是否向主备用或上游备用发送有关当前在备用上执行的查询的反馈。此参数可用于消除由清理记录导致的查询取消，但对于某些工作负载，可能会导致主数据库上的数据库膨胀。反馈消息的发送频率不会超过每个 .
默认值为off

wal_receiver_timeout(int)

描述：终止超过此时间的非活动状态的复制连接。这对于接收备用服务器检测主节点崩溃或网络中断非常有用。如果指定此值时不带单位，则以毫秒为单位。默认值为 60 秒。值为零将禁用超时机制。

wal_retrieve_retry_interval

描述：指定当 WAL 数据无法从任何源（流复制、本地或 WAL 存档）获得时，备用服务器应等待多长时间，然后再尝试检索 WAL 数据。如果指定此值时不带单位，则以毫秒为单位。
默认值为 5 秒。

recovery_min_apply_delay

描述：默认情况下，备用服务器会尽快从发送服务器还原 WAL 记录。拥有数据的延时副本可能很有用，从而提供了纠正数据丢失错误的机会。此参数允许您将恢复延迟指定的时间。例如，如果将此参数设置为5min ，则仅当备用数据库上的系统时间至少比主数据库报告的提交时间晚五分钟时，备用数据库才会重播每个事务提交。如果指定此值时不带单位，则以毫秒为单位。默认值为零，不添加延迟

promote_trigger_file (string)

描述：指定一个触发器文件，该文件的存在会结束后备机中的恢复。
即使这个值没有被设置，你也能够使用pg_ctl promote或调用pg_promote().来提升后备机。

连接和认证相关参数

4.1 连接设置

listen_addresses (string)

描述：PostgreSQL应该监听的IP地址。
默认值：默认值为localhost，特殊项*对应所有可用 IP 接口。项0.0.0.0允许监听所有 IPv4 地址并且::允许监听所有 IPv6 地址。此参数只能在服务器启动时设置。

max_connections (integer)

描述：决定数据库的的最大并发连接数。但是如果内核设置不支持（initdb时决定），可能会比这个 数少。这个参数只能在服务器启动时设置。在运行备用服务器时，必须将此参数设置为与主服务器相同或更高的值。否则，备用服务器中将不允许查询。
默认值：通常为100，但可以根据需要进行调整。调整参数后需要重启数据库才能生效。
示例值：max_connections = 200

port (integer)

描述 ：服务器监听的 TCP 端口；默认是 5432 。服务器监听的所有 IP 地址都使用相同的端口号。
默认值：5432。此参数只能在服务器启动时设置。

reserved_connections (integer)

描述 ：确定为具有 pg_use_reserved_connections 角色权限的角色保留的连接“槽”的数量。只要空闲连接槽的数量大于 superuser_reserved_connections 但小于或等于 superuser_reserved_connections 和 reserved_connections 之和，则仅接受超级用户和具有 pg_use_reserved_connections 权限的角色的新连接。如果 superuser_reserved_connections 或更少的连接槽可用，则仅接受超级用户的新连接。
默认值 ：默认值为零个连接。该值必须小于 max_connections 减去 superuser_reserved_connections。此参数只能在服务器启动时设置。

superuser_reserved_connections (integer)

描述：决定为PostgreSQL超级用户连接而保留的连接“槽”数。 同时活跃的并发连接最多max_connections个。任何时候，活跃的并发连接数最多为max_connections减去 superuser_reserved_connections，新连接就只能由超级用户发起了，并且不会有新的复制连接被接受。
默认值：默认值是 3 连接 。这个值必须小于max_connections。 此参数只能在服务器启动时设置。

tcp_keepalives_idle (integer)

描述：规定在操作系统向客户端发送一个TCP keepalive消息后无网络活动的时间总量。 如果指定值时没有单位，则以秒为单位。值0(默认值)表示选择操作系统默认值。 指定不活动多少秒之后通过 TCP 向客户端发送一个 keepalive 消息。 0 值表示使用默认值。 这个参数只有在支持TCP_KEEPIDLE或等效套接字选项的系统或 Windows 上才可以使用。在其他系统上，它必须为零。在通过 Unix 域套接字连接的会话中，这个参数被忽略并且总是读作零。
注意：在 Windows 上，设定值为0将设置这个参数为 2 小时，因为 Windows 不支持读取系统默认值。

tcp_keepalives_interval (integer)

描述：规定未被客户端确认收到的TCP keepalive消息应重新传输的时间长度。 如果指定值时没有单位，则以秒为单位。值0(默认值)表示选择操作系统默认值。 这个参数只有在支持TCP_KEEPINTVL或等效套接字选项的系统或 Windows 上才可以使用。在其他系统上，必须为零。

tcp_keepalives_count (integer)

描述：指定服务器到客户端的连接被认为中断之前可以丢失的TCP keepalive消息的数量。值0(默认值)表示选择操作系统默认值。 这个参数只有在支持TCP_KEEPCNT或等效套接字选项的系统上才可以使用。在其他系统上，必须为零

tcp_user_timeout (integer)

描述：指定传输的数据在TCP连接被强制关闭之前可以保持未确认状态的时间量。 如果指定值时没有单位，则以毫秒为单位。值0(默认值)表示选择操作系统默认值。 这个参数只有在支持TCP_USER_TIMEOUT的系统上才被支持；在其他系统上，它必须为零。

client_connection_check_interval (integer)

描述：在运行查询时，设置检查客户端是否保持连接的可选检查的时间间隔。 这个检查通过轮询套接字来执行，并且在内核报告该连接关闭时，允许长时间运行的查询可以尽快中止。这个选项当前仅在支持非标的POLLRDHUP扩展到poll系统调用的系统上有效，包括Linux。

默认值：如果指定的值没有单位，则以毫秒为单位。 默认值为0，代表禁用连接检查。 没有连接检查，服务器将只在与套接字的下一次交互时检测连接的丢失，当它等待、接收或发送数据时。

unix_socket_directories (string)

描述：指定 Unix 域套接字的目录，服务器要在其上侦听来自客户端应用程序的连接。可以通过列出以逗号分隔的多个目录来创建多个套接字。条目之间的空格将被忽略;如果需要在名称中包含空格或逗号，请用双引号将目录名称括起来。空值指定不侦听任何 Unix 域套接字，在这种情况下，只能使用 TCP/IP 套接字连接到服务器。
默认值：/tmp。在 Windows 上，默认值为空。此参数只能在服务器启动时设置。
说明：除了套接字文件本身（其名称为 .s.PGSQL.nnnn，其中 nnnn 是服务器的端口号）之外，还将在每个 unix_socket_directories 目录中创建一个名为 .s.PGSQL.nnnn.lock 的普通文件。这两个文件都不得手动删除。对于抽象命名空间中的套接字，不会创建锁定文件。

unix_socket_group (string)

描述：设置 Unix 域套接字的所属组。（套接字的拥有者始终是启动服务器的用户。结合该参数，这可以用作 Unix 域连接的附加访问控制机制。默认情况下，这是空字符串，它使用服务器用户的默认组。此参数只能在服务器启动时设置。此参数在 Windows 上不受支持。任何设置都将被忽略。此外，抽象命名空间中的套接字没有文件所有者，因此在这种情况下也会忽略此设置。

unix_socket_permissions(integer)

描述：设置 Unix 域套接字的访问权限。Unix 域套接字使用通常的 Unix 文件系统权限集。参数值应为 chmod和 umask0系统调用所接受的格式中指定的数值模式。（若要使用惯用的八进制格式，数字必须以（零）开头。

默认值：默认权限为 0777，表示任何人都可以连接。合理的替代方案是 0770（仅用户和组）和 0700（仅用户）。（请注意，对于 Unix 域套接字，只有写权限才有意义，因此设置或撤销读或执行权限没有任何意义。）此参数只能在服务器启动时设置。抽象命名空间中的套接字没有文件权限，因此在这种情况下也会忽略此设置。

client_encoding (string)

描述：参数指定了客户端与服务器之间进行通信时所使用的字符编码方式。它决定了客户端发送到服务器的数据如何被解释和处理，以及服务器发送给客户端的数据如何被解码和显示。
作用：控制客户端与服务器之间的文本数据传输编码方式。这对于确保数据在不同语言环境或国家/地区设置下的正确显示和解释至关重要。

常见取值：常见取值包括 SQL_ASCII、UTF8（或 UTF-8）、LATIN1 等。其中：

UTF8 是最常用的 Unicode 编码，支持大多数国际字符集。
SQL_ASCII` 表示无特定字符集，直接按字节传输数据，不进行编码转换。
修改后会立刻生效，不需要重启数据库。在创建数据库或连接数据库时，应确保客户端和服务器的 client_encoding 设置一致，以避免数据不一致或错误解释的问题。如果客户端的字符编码与服务器设置不一

安全与认证

authentication_timeout (integer)

描述：允许完成客户端认证的最长时间。如果一个客户端没有在这段时间里完成认证协议，服务器将关闭连接。 这样就避免了出问题的客户端无限制地占有一个连接。如果指定值时没有单位，则以秒为单位。

默认值：默认值是 1分钟（1m）。

password_encryption (enum)

描述：当在CREATE ROLE或者ALTER ROLE中指定了口令时，这个参数决定用于加密该口令的算法。 可能的值是 scram-sha-256, 可以用SCRAM-SHA-256, 和 md5加密密码，以MD5 哈希的方式存储密码。 默认为 scram-sha-256。

krb_server_keyfile (string)

描述：设置服务器的Kerberos密钥文件的位置。 默认为FILE:/usr/local/pgsql/etc/krb5.keytab（其中目录部分是在构建时由sysconfdir指定的；用pg_config --sysconfdir来决定）。 如果这个参数被设为空字符串，它将被忽略，并且系统依赖的默认值被应用。

krb_caseins_users (boolean)

描述：设置是否应该以大小写不敏感的方式对待GSSAPI用户名。默认值是off（大小写敏感）。

db_user_namespace (boolean)

描述：这个参数启用针对每个数据库的用户名。这个参数默认是关掉的。

如果这个参数为打开，应该把用户创建成username@dbname的形式。当一个连接客户端传来username时，@和数据库名会被追加到用户名并且服务器会查找这个与数据库相关的用户名。注意在SQL环境中用含有@的名称创建用户时，需要把用户名放在引号内。

在这个参数被启用时，仍然可以创建平常的全局用户。而在客户端中指定这种用户时只需要简单地追加@，例如joe@。在服务器查找该用户名之前，@会被剥离掉。

db_user_namespace会导致客户端和服务器的用户名表达形式不同。认证检查总是会以服务器的用户名表达形式来完成，因此认证方法必须针对服务器用户名而不是客户端用户名来配置。由于md5方法在客户端和服务器两端都使用用户名作为salt，md5不能与db_user_namespace同时使用。

scram_iterations (integer)

描述：使用 SCRAM-SHA-256 加密密码时要执行的计算迭代次数。默认值为 4096。较高的迭代次数可为存储的密码提供额外的暴力破解保护，但会使身份验证变慢。更改此值不会对使用 SCRAM-SHA-256 加密的现有密码产生影响，因为迭代次数在加密时是固定的。为了使用更改后的值，必须设置新密码。
默认值：默认值为 4096。

pg_hba.conf 配置文件中的认证相关参数
TYPE    DATABASE     USER      ADDRESS      METHOD

TYPE：可以是local（匹配使用Unix域套接字的连接）或host（匹配使用TCP/IP建立的连接）。
DATABASE：指定数据库名，或使用all表示所有数据库。
USER：指定用户名，或使用all表示所有用户。
ADDRESS：指定客户端IP地址或主机名，或使用CIDR表示法指定IP地址范围。
METHOD：指定认证方法，如trust、reject、md5、password等。

SSL连接

ssl (boolean)

描述：启用SSL连接。
默认值：默认值是off。

ssl_ca_file (string)

描述：指定包含 SSL 服务器证书颁发机构 （CA） 的文件的名称。相对路径是相对于数据目录的。
默认值：默认值为空，表示未加载 CA 文件，并且不执行客户端证书验证。

ssl_cert_file(string)

描述：指定包含 SSL 服务器证书的文件的名称。相对路径是相对于数据目录的。此参数只能在文件或服务器命令行中设置。
默认值：默认值为server.crt。

ssl_crl_file(string)

描述：指定包含 SSL 客户端证书吊销列表 （CRL） 的文件的名称。相对路径是相对于数据目录的。此参数只能在文件或服务器命令行中设置。默认值为空，表示不加载 CRL 文件（除非设置了ssl_crl_dir）。

ssl_crl_dir(string)

描述：使用此设置时，将在连接时按需加载指定目录中的 CRL。可以将新的 CRL 添加到目录，并且会立即使用它们。这与 ssl_crl_file 不同，后者会导致在服务器启动时或重新加载配置时加载文件中的 CRL。两种设置可以一起使用。

ssl_key_file(string)

描述：指定包含 SSL 服务器私钥的文件的名称。相对路径是相对于数据目录的。此参数只能在文件或服务器命令行中设置。
默认值：默认值为server.key。

ssl_ciphers(string)

描述：指定允许 SSL 连接使用的 SSL 密码套件的列表。有关此设置的语法和支持的值列表，请参阅 OpenSSL 包中的密码手册页。
参数默认值说明：


HIGH
使用 HIGH 组密码的密码套件（例如，AES、Camellia、3DES）

MEDIUM
使用 MEDIUM 组密码的密码套件（例如，RC4、SEED）

+3DES
由于 HIGH 的 OpenSSL 默认顺序将 3DES 排在 AES128 之前，因此存在问题。这是错误的，因为 3DES 提供的安全性低于 AES128，而且速度也慢得多。 +3DES 将其重新排序到所有其他 HIGH 和 MEDIUM 密码之后。

!aNULL·
禁用不进行身份验证的匿名密码套件。此类密码套件容易受到 MITM 攻击，因此不应使用。

可用的密码套件详细信息因 OpenSSL 版本而异。使用命令 openssl ciphers -v 'HIGH:MEDIUM:+3DES:!aNULL' 查看当前已安装 OpenSSL 版本的实际详细信息。请注意，此列表在运行时会根据服务器密钥类型进行筛选。

ssl_prefer_server_ciphers(string)

描述：定是否使用服务器的 SSL 密码首选项，而不是客户端的密码首选项。此参数只能在文件或服务器命令行中设置。

ssl_ecdh_curve(string)

描述：指定要在 ECDH 密钥交换中使用的曲线的名称。它需要得到所有连接客户端的支持。它不需要与服务器的椭圆曲线键使用的曲线相同。此参数只能在文件或服务器命令行中设置。
默认值：为prime256v1。

ssl_min_protocol_version(string)

描述：设置要使用的最低 SSL/TLS 协议版本。当前有效值为：TLSv1、TLSv1.1、TLSv1.2、TLSv1.3。旧版本的 OpenSSL 库不支持所有值;如果选择不受支持的设置，将引发错误。TLS 1.0 之前的协议版本（即 SSL 版本 2 和 3）始终处于禁用状态
默认值：默认值为TLSv1.2。

ssl_max_protocol_version(string)

描述：设置要使用的最大 SSL/TLS 协议版本。有效值与ssl_min_protocol_version相同，并添加了一个空字符串，该字符串允许任何协议版本。默认设置是允许任何版本。设置最大协议版本主要用于测试，或者某些组件在使用较新的协议时遇到问题。此参数只能在 postgresql.conf 文件或服务器命令行中设置。

ssl_dh_params_file(string)

描述：指定包含用于所谓的临时 DH 系列 SSL 密码的 Diffie-Hellman 参数的文件的名称。默认值为空，在这种情况下，使用编译的默认 DH 参数。如果攻击者设法破解已知编译的 DH 参数，使用自定义 DH 参数可减少暴露。您可以使用命令创建自己的 DH 参数文件。此参数只能在 postgresql.conf 文件或服务器命令行中设置。

ssl_passphrase_command(string)

描述：设置在需要获取用于解密 SSL 文件（如私钥）的密码时要调用的外部命令。默认情况下，此参数为空，表示使用内置提示机制。此参数只能在 postgresql.conf 文件或服务器命令行中设置。

ssl_passphrase_command_supports_reload(string)

描述：此参数确定如果密钥文件需要密码，则在重新加载配置期间是否也会调用 设置的密码命令。如果此参数处于关闭状态（默认值），则在重新加载期间将被忽略，并且在需要密码短语时不会重新加载 SSL 配置。此参数只能在 postgresql.conf 文件或服务器命令行中设置。

查询规划参数

Planner方法配置

enable_async_append (boolean)

描述：激活或禁用查询计划的关于异步感知附加计划类型的使用。 默认为on。

enable_bitmapscan (boolean)

描述：允许或禁止查询规划器使用位图扫描计划类型。默认值是on。

enable_gathermerge (boolean)

描述：启用或者禁用查询规划器对收集归并计划类型的使用。默认值是on。

enable_hashagg (boolean)

描述：允许或禁用查询规划器使用哈希聚集计划类型。默认值是on。

enable_hashjoin (boolean)

描述：允许或禁止查询规划器使用哈希连接计划类型。默认值是on。

enable_incremental_sort (boolean)

描述：启用或禁用查询规划器对增量排序步骤的使用。默认为on。

enable_indexscan (boolean)

描述：允许或禁止查询规划器使用索引扫描计划类型。默认值是on。

enable_indexonlyscan (boolean)

描述：允许或禁止查询规划器使用只用索引扫描计划类型。默认值是on。

enable_material (boolean)

描述：允许或者禁止查询规划器使用物化。它不可能完全禁用物化，但是关闭这个变量将阻止规划器插入物化节点，除非为了保证正确性。默认值是on。

enable_memoize (boolean)

描述：启用或禁用查询计划器对memoize计划的使用，以便缓存在嵌套循环连接中参数化扫描的结果。 在当前参数的结果已经在缓存中时，此计划类型允许跳过对底层计划的扫描。 当新条目需要更多空间时，不太常用的查询结果可能会从缓存中去除。 默认值是on。

enable_mergejoin (boolean)

描述：允许或禁止查询规划器使用归并连接计划类型。默认值是on。

enable_nestloop (boolean)

描述：允许或禁止查询规划器使用嵌套循环连接计划。它不可能完全禁止嵌套循环连接，但是关闭这个变量将使得规划器尽可能优先使用其他方法。默认值是on。

enable_parallel_append (boolean)

描述：允许或禁止查询规划器使用并行追加计划类型。默认值是on。

enable_parallel_hash (boolean)

描述：允许或禁止查询规划器对并行哈希使用哈希连接计划类型。如果哈希连接计划也没有启用，这个参数没有效果。默认值是on。

enable_partition_pruning (boolean)

描述：允许或者禁止查询规划器从查询计划中消除一个分区表的分区。这也控制着规划器产生允许执行器在查询执行期间移除（忽略）分区的查询计划的能力。默认值是on。

enable_partitionwise_join (boolean)

描述：允许或者禁止查询规划器使用面向分区的连接，这使得分区表之间的连接以连接匹配的分区的方式来执行。 面向分区的连接当前只适用于连接条件包括所有分区键的情况，连接条件必须是相同的数据类型并且子分区集合要1对1匹配。 由于面向分区的连接规划在规划期间会使用可观的CPU时间和内存，所以默认值为off。

enable_partitionwise_aggregate (boolean)

描述：允许或者禁止查询规划器使用面向分区的分组或聚集，这使得在分区表上的分组或聚集可以在每个分区上分别执行。如果GROUP BY子句不包括分区键，只有部分聚集能够以基于每个分区的方式执行，并且finalization必须最后执行。由于面向分区的分组或聚集在规划期间会使用可观的CPU时间和内存，所以默认值为off。

enable_seqscan (boolean)

描述：允许或禁止查询规划器使用顺序扫描计划类型。它不可能完全禁止顺序扫描，但是关闭这个变量将使得规划器尽可能优先使用其他方法。默认值是on。

enable_sort (boolean)

描述：允许或禁止查询规划器使用显式排序步骤。它不可能完全禁止显式排序，但是关闭这个变量将使得规划器尽可能优先使用其他方法。默认值是on。

enable_tidscan (boolean)

描述：允许或禁止查询规划器使用TID扫描计划类型。默认值是on。

Planner成本参数设置

seq_page_cost (floating point)

描述：设置规划器计算一次顺序磁盘页面抓取的开销。默认值是1.0。 通过设置同名的表空间参数，这个值可以重写为一个特定的表空间。 参阅ALTER TABLESPACE。 设置规划器对一系列顺序磁盘页面获取中的一次的代价估计。默认值是 1.0。通过把表和索引放在一个特殊的表空间（要设置该表空间的同名参数）中可以覆盖这个值
random_page_cost (floating point)

描述：设置规划器对一次非顺序获取磁盘页面的代价估计。默认值是 4.0。通过把表和索引放在一个特殊的表空间（要设置该表空间的同名参数）中可以覆盖这个值。

减少这个值（相对于seq_page_cost）将导致系统更倾向于索引扫描；提高它将让索引扫描看起来相对更昂贵。你可以一起提高或降低两个值来改变磁盘 I/O 代价相对于 CPU 代价的重要性，后者由下列参数描述。

对磁盘存储的随机访问通常比顺序访问要贵不止四倍。但是，由于对磁盘的大部分随机访问（例如被索引的读取）都被假定在高速缓冲中进行，所以使用了一个较低的默认值（4.0）。默认值可以被想成把随机访问建模为比顺序访问慢 40 倍，而期望 90% 的随机读取会被缓存。

注意：虽然允许你将random_page_cost设置的比 seq_page_cost小，但是物理上的实际情况并不受此影响。 然而当所有数据库都位于内存中时，两者设置为相等是非常合理的，因为 在此情况下，乱序抓取并不比顺序抓取开销更大。同样，在缓冲率很高的 数据库上，你应当相对于 CPU 开销同时降低这两个值，因为获取内存中 的页比通常情况下的开销小许多。 尽管系统可以是你把random_page_cost设置得小于seq_page_cost，但是实际上没有意义。不过，如果数据库被整个缓存在 RAM 中，将它们设置为相等是有意义的，因为在那种情况中不按顺序访问页面是没有惩罚值的。同样，在一个高度缓存化的数据库中，你应该相对于 CPU 参数降低这两个值，因为获取一个已经在 RAM 中的页面的代价要远小于通常情况下的代价。

cpu_tuple_cost (floating point)

描述：设置规划器对一次查询中处理每一行的代价估计。默认值是 0.01。

cpu_index_tuple_cost (floating point)

描述：设置规划器对一次索引扫描中处理每一个索引项的代价估计。默认值是 0.005

cpu_operator_cost (floating point)

描述：设置规划器对于一次查询中处理每个操作符或函数的代价估计。默认值是 0.0025。

parallel_setup_cost (floating point)

描述：设置规划器对启动并行工作者进程的代价估计。默认是 1000。

parallel_tuple_cost (floating point)

描述：设置规划器对于从一个并行工作者进程传递一个元组给另一个进程的代价估计。默认是 0.1。

min_parallel_table_scan_size (integer)

描述：为必须扫描的表数据量设置一个最小值，扫描的表数据量超过这一个值才会考虑使用并行扫描。 对于并行顺序扫描，被扫描的表数据量总是等于表的尺寸，但是在使用索引时，被扫描的表数据量通常会更小。 如果指定值时没有单位，则以块为单位，即BLCKSZ字节，通常为8kB。默认值是8兆字节（8MB）

min_parallel_index_scan_size (integer)

描述：为必须扫描的索引数据量设置一个最小值，扫描的索引数据量超过这一个值时才会考虑使用并行扫描。 注意并行索引扫描通常并不会触及整个索引，它是规划器认为该扫描会实际用到的相关页面的数量。 这个参数还用于决定特定的索引是否参与并行vacuum。如果指定值时没有单位，则以块为单位，即BLCKSZ字节，通常为8kB。默认值是512千字节（512kB）。

effective_cache_size (integer)

描述：设置规划器对一个单一查询可用的有效磁盘缓冲区尺寸的假设。 这个参数会被考虑在使用一个索引的代价估计中，更高的数值会使得索引扫描更可能被使用，更低的数值会使得顺序扫描更可能被使用。
默认值：如果指定值时没有单位，则以块为单位，即BLCKSZ字节，通常为8kB。 默认值是 4吉字节（4GB）。修改后需要重启数据库生效。

该参数实际上与具体的内存分配没有关系，它是告诉优化器在估计SQL的执行代价时假设有多少磁盘缓存，注意主要指文件系统缓存，通常设置为机器总内存的80%，设置得多一些（如90%）或少一些（如50%）并不会有严重的影响。

jit_above_cost (floating point)

描述：设置激活JIT编译的查询代价，如果查询代价超过这个值就会激活JIT编译。执行JIT会消耗一些规划时间，但是能够加速查询执行。将这个值设置为-1会禁用JIT编译。默认值是100000。

jit_inline_above_cost (floating point)

描述：设置JIT编译尝试内联函数和操作符的查询代价阈值，如果查询代价超过这个值，JIT编译就会尝试内联。内联会增加规划时间，但是可以提高执行速度。将这个参数设置成小于jit_above_cost是没有意义的。将这个参数设置为-1会禁用内联。默认值是500000。

jit_optimize_above_cost (floating point)

描述：设置JIT编译应用优化的查询代价阈值，如果查询代价超过这个值，JIT编译就会应用开销较大的优化。这类优化会增加规划时间，但是更能够改进执行速度。将这个参数设置成小于jit_above_cost是没有意义的，并且将它设置成大于jit_inline_above_cost也未必有益。将这个参数设置为-1会禁用开销较大的优化。默认值是500000。

遗传查询优化

GEQO是一个使用探索式搜索来执行查询规划的算法。它可以降低负载查询的规划时间。 同时，GEQO的检索是随机的，因此它的规划可能会不可确定。 更多信息参阅Chapter 50。 遗传查询规划器（GEQO）是一种使用启发式搜索来进行查询规划的算法。它可以降低对于复杂查询（连接很多表的查询）的规划时间，但是代价是它产生的计划有时候要差于使用穷举搜索算法找到的计划。

geqo (boolean)

描述:允许或禁止遗传查询优化。默认是启用。在生产环境中通常最好不要关闭它。geqo_threshold变量提供了对 GEQO 更细粒度的空值。

geqo_threshold (integer)

描述：只有当涉及的FROM项数量至少有这么多个的时候，才使用遗传查询优化（注意一个FULL OUTER JOIN只被计为一个FROM项）。默认值是 12。对于更简单的查询，通常会使用普通的穷举搜索规划器，但是对于有很多表的查询穷举搜索会花很长时间，通常比执行一个次优的计划带来的惩罚值还要长。因此，在查询尺寸上的一个阈值是管理 GEQO 使用的一种方便的方法。

geqo_effort (integer)

描述：控制 GEQO 里规划时间和查询规划的有效性之间的平衡。这个变量必须是 一个范围从 1 到 10 的整数。缺省值是 5 。大的数值增加花在进行查询 规划上面的时间，但是也很可能会提高选中更有效的查询规划的几率。 控制 GEQO 中规划时间和查询计划质量之间的折中。这个变量必须是位于 1 到 10 之间的一个整数。默认值是 5。更大的值会增加花在查询规划上的时间，但是同时也增加了选择一个高效查询计划的可能性。

geqo_pool_size (integer)

描述：控制 GEQO 使用的池尺寸，它就是遗传种群中的个体数目。它必须至少为 2，且有用的值通常在 100 到 1000 之间。如果它被设置为零（默认设置）则会基于geqo_effort和查询中表的数量选择一个合适的值。

geqo_generations (integer)

描述：控制 GEQO 使用的子代数目。子代的意思是算法的迭代次数。它必须至少 是 1 ，有用的值范围和池大小相同。如果设置为零(缺省)，那么将基于 geqo_pool_size选取合适的值。 控制 GEQO 使用的代数，也是算法的迭代次数。它必须至少为 1，并且有用值的范围和池尺寸相同。如果它被设置为零（默认设置）则会基于geqo_pool_size选择一个合适的值。

geqo_selection_bias (floating point)

描述：控制 GEQO 使用的选择偏好。选择偏好是种群中的选择压力。值可以是 1.5 到 2.0 之间，后者是默认值。
geqo_seed (floating point)
描述：控制 GEQO 使用的随机数生成器的初始值，随机数生成器用于在连接顺序搜索空间中选择随机路径。该值可以从 0 （默认值）到 1。变化该值会改变被探索的连接路径集合，并且可能导致找到一个更好或更差的路径。

其他Planner选项

default_statistics_target (integer)

描述：为没有通过ALTER TABLE SET STATISTICS设置列相关目标的表列设置默认统计目标。更大的值增加了需要做ANALYZE的时间，但是可能会改善规划器的估计质量。默认值是 100。

constraint_exclusion (enum)

描述：控制查询规划器对表约束的使用，以优化查询。 constraint_exclusion的允许值是on（对所有表检查约束）、off（从不检查约束）和partition（只对继承的子表和UNION ALL子查询检查约束）。 partition是默认设置。它通常与传统的继承树一起使用来提高性能。

cursor_tuple_fraction (floating point)

描述：设置规划器对将被检索的一个游标的行的比例的估计。默认值是 0.1。更小的值使得规划器偏向为游标使用“快速开始”计划，它将很快地检索前几行但是可能需要很长时间来获取所有行。更大的值强调总的估计时间。最大设置为 1.0，游标将和普通查询完全一样地被规划，只考虑总估计时间并且不考虑前几行会被多快地返回。

from_collapse_limit (integer)

描述：如果生成的FROM列表不超过这么多项，规划器将把子查询融合到上层查询。较小的值可以减少规划时间，但是可能 会生成较差的查询计划。默认值是 8。
注意：将这个值设置为geqo_threshold或更大，可能触发使用 GEQO 规划器，从而产生非最优计划。

jit (boolean)

描述：PostgreSQL是否可以使用JIT编译。默认值是on

join_collapse_limit (integer)

描述：默认情况下，这个变量被设置成和from_collapse_limit相同， 这样适合大多数使用。把它设置为 1 可避免任何显式JOIN的重排序。因此查询中指定的显式连接顺序就是关系被连接的实际顺序。因为查询规划器并不是总能 选取最优的连接顺序，高级用户可以选择暂时把这个变量设置为 1，然后显式地指定他们想要的连接顺序。
注意：将这个值设置为geqo_threshold或更大，可能触发使用 GEQO 规划器，从而产生非最优计划。

plan_cache_mode (enum)

描述：准备语句（显式准备或隐式生成的，例如 PL/pgSQL）可以使用自定义或通用计划执行。 使用其特定的参数值集为每个执行重新生成自定义计划，而通用计划不依赖于参数值，并且可以在执行中重复使用。 因此，使用通用计划可以节省计划时间，但如果理想计划严重依赖参数值，则通用计划可能效率低下。 这些选项之间的选择通常是自动进行的，但可以通过plan_cache_mode覆盖它。 允许的值为 auto (默认的),force_custom_plan 和 force_generic_plan。 这个设置是在执行缓存计划时考虑，而不是在准备计划时考虑。

日志参数

在哪里做日志

log_destination

描述：指定需要输出日志格式

默认：stderr

可选：

stderr：日志打印到标准错误输出（stderr），通常是在控制台或终端窗口中。
csvlog：日志以 CSV（逗号分隔值）格式写入到文件中。使用 csvlog 时，通常需要启用 logging_collector 参数。
syslog：日志通过操作系统的 syslog 机制记录。在 Unix 系统上，PostgreSQL 可以在 syslog 设备 LOCAL0 到 LOCAL7 中记录。在 Windows 上，这个选项不适用。
eventlog（仅 Windows）：日志写入 Windows 事件日志。
如果你想将日志同时输出到标准错误和 CSV 文件，你可以设置 log_destination = 'stderr,csvlog'。

注意：在大多数 Unix 系统上，你将需要修改系统的syslog守护进程的配置来使用log_destination的syslog选项。PostgreSQL可以在syslog设备LOCAL0到LOCAL7中记录（见syslog_facility），但是大部分平台上的默认syslog配置会丢弃所有这种消息。你将需要增加这样的内容：

local0.*    /var/log/postgresql
logging_collect

描述：是否启动日志收集器，它是一个捕捉被发送到stderr的日志消息的后台进程，并且它会将这些消息重定向到日志文件中
默认值：off（不启动）
注意：日志收集器被设计成从来不会丢失消息。这意味着在极高的负载下，如果服务器进程试图在收集器已经落后时发送更多的日志消息，那么它会被阻塞。相反，syslog倾向于在无法写入消息时丢掉消息，这意味着在这样的情况下它可能会无法记录某些消息，但是它不会阻塞系统的其他部分。

log_directory

描述：当logging_collector被启用时，这个参数决定日志文件将被在哪个目录下创建。

默认值：默认是log。它可以被指定为一个绝对路径，也可以被指定为一个相对于集簇数据目录的相对路径。如‘pg_log’。

log_file_mode

描述：这个参数设置日志文件的权限（在微软 Windows 上这个参数将被忽略）。这个参数值应当是一个数字形式的模式，它可以被chmod和umask系统调用接受（要使用通常的十进制格式，该数字必须以一个0（零）开始）。

log_rotation_size

描述：当logging_collector被启用时，这个参数决定一个个体日志文件的最大尺寸。
默认：24MB
0表示不限制日志大小

log_rotation_age (integer)

描述：当logging_collector被启用时，这个参数决定使用一个单个日志文件的最大时间量，之后将创立一个新的日志文件。
如果指定值时没有单位，则以分钟为单位。默认为24小时。 将这个参数设置为零将禁用基于时间的新日志文件创建。
log_statement

描述：控制需要记录的sql类型（或仅记录DDL/DML/DML_ROW/ALL等特定类型）。
默认值：none（不记录）。更改 log_statement 的值后，日志记录行为会立即改变，新的设置会在下个日志条目中生效，无需重启数据库。
可选：‘none’, ‘ddl’, ‘mod’, 或 ‘all’。
log_filename

描述：当logging_collector被启用时，这个参数设置被创建的日志文件的文件名。

例如：'postgresql-%Y-%m-%d_%H%M%S.log'。

log_replication_commands

描述：开启记录流复制记录
默认：off 不开启
log_truncate_on_rotation (boolean)

描述:当logging_collector被启用时，这个参数将导致PostgreSQL截断（覆盖而不是追加）任何已有的同名日志文件。
syslog_facility (enum)

描述：当启用了向syslog记录时，这个参数决定要使用的syslog“设备”。你可以在LOCAL0、LOCAL1、LOCAL2、LOCAL3、LOCAL4、 LOCAL5、LOCAL6、LOCAL7中选择，默认值是LOCAL0。
syslog_ident (string)

描述：当启用了向syslog记录时，这个参数决定用来标识syslog中的PostgreSQL消息的程序名。默认值是postgres。
syslog_sequence_numbers (boolean)

描述：当日志被记录到syslog并且这个设置为 on （默认）时，每一个消息会被加上一个增长的序号作为前缀（例如[2]）。这种行为避开了很多 syslog 实现默认采用的“— 上一个消息重复 N 次 —”形式。在现代 syslog 实现中，抑制重复消息是可以配置的（例如rsyslog中的$RepeatedMsgReduction），因此这个参数可能不是必需的。此外，如果你真的想抑制重复消息，你可以把这个参数设置为 off。
syslog_split_messages (boolean)

描述：当启用把日志记录到syslog时，这个参数决定消息如何送达 syslog。当设置为 on（默认）时，消息会被分成行，并且长的行也会被划分以便能够放到 1024 字节中，这是传统 syslog 实现一种典型的尺寸限制。当设置为 off 时，PostgreSQL 服务器日志消息会被原样送达 syslog 服务，而处理可能的大体量消息的任务由 syslog 服务负责。
event_source (string)

描述：当启用了向事件日志记录时，这个参数决定用来标识日志中PostgreSQL消息的程序名。默认值是PostgreSQL。

使用PGTune工具来配置参数

对于朋友这样的公司，没有DBA专业人士，我一般会建议他们使用PGTune来配置参数，这款工具是在线软件，链接地址。设置很简单，你只需要知道你的数据库版本，操作系统类型，内存数量，CPU数量，磁盘类型，连接数，还有应用的类型。就可以轻轻松松得到一些建议的参数值。

使用postgresqltuner来优化参数

当然我们还可以使用postgresqltuner工具来优化参数，作者说受到了mysqltuner的启发，它是perl脚本写的。链接地址

这个软件使用起来也很简单，直接下载解压，执行脚本就行了。

postgresqltuner.pl --host=dbhost --database=testdb --user=username --password=qwerty

这个软件要比PGTune要专业一些，它还输出了一些操作系统的配置，同时它根据数据库当前的负载来判断内存参数是否合理，类似于Advisor。

总结

最后来做个ending吧，系统默认的配置只适合自己玩玩，并不适合开箱即用。还是需要根据DBA的专业经验来进行相关参数的配置，如果没有专业的DBA童鞋，也可以使用PGTune或者是postgresqltuner脚本来进行一些优化，做完这些优化，系统性能将会大幅提升。

#01 - Connection-Authentication
优化点：

listen_addresses = '0.0.0.0'
建议：生产环境应限制为具体IP（如 '192.168.1.0/24,127.0.0.1'），避免暴露到公网。

ssl = off
建议：启用SSL（ssl = on），配置证书提升安全性。

superuser_reserved_connections = 10
建议：降低至 3，避免普通连接不足。

#02 - Memory-Resource
关键调整：

shared_buffers = 1GB
建议：设为物理内存的 25%-30%（若总内存≥8GB，可设为 4GB）。

work_mem = 5592kB
建议：根据并发调整（如 4MB），公式参考：work_mem = (总内存 - shared_buffers) / (max_connections * 2)。

effective_cache_size = 3GB
建议：设为物理内存的 50%-75%（若总内存≥8GB，建议 6GB）。

huge_pages = try
建议：若系统支持且内存>64GB，设为 on 提升性能。

#03 - WAL-Checkpoint-Archiving
优化点：

synchronous_commit = off
风险：可能丢失少量事务。若需高持久性，设为 on 或 remote_apply（集群场景）。

wal_buffers = 16MB
建议：通常设为 shared_buffers 的 1/32（若 shared_buffers=4GB，设为 128MB）。

archive_command
验证：确保 /postgresql/log/archive/ 路径存在且权限正确，建议添加错误重试逻辑（如 cp %p ... || exit 1）。

#04 - Replication
优化点：

max_wal_senders = 32
建议：根据实际从库数量调整，通常 主库数 + 2。

track_commit_timestamp = on
用途：若需逻辑复制（如CDC），保持开启；否则关闭以减少开销。

#05 - Reporting-Logging
关键调整：

log_min_duration_statement = 1000
建议：设为 100ms 以捕获更多慢查询。

log_statement = 'ddl'
建议：若需审计所有操作，设为 all；否则保持默认。

日志存储：确保 /postgresql/log/pg_log 路径有足够空间，建议日志定期清理或归档。

#06 - QueryTuning-Statistics-Autovacuum
优化点：

autovacuum_max_workers = 5
建议：若表多或写入频繁，可增至 6-8。

autovacuum_vacuum_scale_factor = 0.2
建议：添加此参数，替代默认的 0.2（更积极清理：autovacuum_vacuum_scale_factor = 0.05）。

maintenance_work_mem = 256MB
建议：设为 1GB 以加速VACUUM和索引创建。

#07 - Lock
优化点：

deadlock_timeout = 5s
建议：保持默认 1s，避免长锁等待。

#08 - Client Connection
无需调整：时区、本地化设置合理。

#09 - pg_stat_statements-auto_explain
优化点：

auto_explain.log_min_duration = 10s
建议：设为 1s 以捕获更多执行计划。

注意：auto_explain.log_analyze = true 会显著增加日志量，生产环境建议仅在调试时开启。

原文链接：https://blog.csdn.net/zyb378747350/article/details/148176007

参考文档

https://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Serverhttps://www.percona.com/blog/2018/08/31/tuning-postgresql-database-parameters-to-optimize-performance/

posted @ 2026-05-18 13:58  数据库小白（专注）  阅读(25)  评论(0)    收藏  举报