PostgreSQL的“犄角旮旯“的参数捋一捋-CSDN博客

本文链接：https://blog.csdn.net/liuhuayang/article/details/147201264

❝
开头还是介绍一下群，如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, OceanBase, Sql Server等有问题，有需求都可以加群群内有各大数据库行业大咖，可以解决你的问题。加群请联系 liuaustin3 ，（共2760人左右 1 + 2 + 3 + 4 +5 + 6 + 7 + 8 +9）(1 2 3 4 5 6 7群均已爆满，，开8群200+ 9群)

PostgreSQL 的一些参数，已经有人私信我，想要一个比较官方的参数的释义，然后我就有了一个想法关于把一些更新的参数来说一说，这个会有几期来说一说，希望能帮助大家。

首先这里有一个网站关于POSTGRESQL的一些基本的参数的调节网站。

https://pgtune.leopard.in.ua/?dbVersion=16&osType=linux&dbType=web&cpuNum=4&totalMemory=16&totalMemoryUnit=GB&connectionNum=100&hdType=ssd

PGTune

好了，这期叫POSTGRESQL 犄角旮旯的参数，那么这些参数必然是大家平时不太关心的参数，下期咱们说说重要的参数，这期的参数大家可能看着也没有什么，看见这些参数也不知道是什么意思，那么咱们就来说说这些参数。

https://postgresqlco.nf/doc/en/param/allow_in_place_tablespaces/ https://www.percona.com/blog/postgresql-parameters-scope-and-priority-users-should-know/

1 allow_alter_system

一般很少有人提到这个参数，这个参数算是犄角旮旯的PG参数之一了，但是你说他有没有用

[postgres@PG17 ~]$ psql
psql (17.4)
Type "help" for help.

postgres=# alter system set work_mem = '5MB';
ERROR:  ALTER SYSTEM is not allowed in this environment
postgres=#

这个参数主要的作用是限制任何的用户在命令行中通过alter system 修改系统的参数，这个参数的意义在于一些管理上有失误的企业，无法严格控制核心参数修改的权限，或者私有云，公用云怕用户在系统上乱修改参数然后reload，的一个“粗野” 的解决方案，那么用户要修改参数就必须和postgresql.conf, postgresql.auto.conf打交道了。

2 allow_in_place_tablespaces

这个参数估计也是知道的人不多，这个参数实际的意义是比较大的，尤其在一些特殊的需求下，我们先说说需求，举例你的PG数据库的数据目录要统一放到一个新的挂在点上，比如从 /data/ 挂在到 /data2 上，实际上我们只是在LINUX 上重新规划挂载点，实际的数据是不需要进行改变的，但是如果我们使用的修改tablespace的命令将挂载点转换到另一个tablespace的时候，就会启动COPY，所以将这个打开后，在进行更换tablespace的时候，就不会触发copy的方式来处理数据。

3 enable_memoize

这个参数默认是开启的，主要的功能是缓存小表的数据，在进行子查询中的小表和上层表之间的处理

可以从扫描表变换到内存的扫描,有助于PG的执行SQL的速度，这个参数是从PG14引入的。

Nested Loop (cost=... rows=...)
  -> Seq Scan on large_table
  -> Index Scan using small_table_pkey on small_table

Nested Loop
  -> Seq Scan on large_table
  -> Memoize
      Cache Key: l.id
      Cache Mode: logical
      Hits: 1000  Misses: 50
  -> Index Scan using small_table_pkey on small_table

4 db_user_namespace

这个参数很少被提及，但在POSTGRESQL中我们不得不提出一个租户的概念，比如你有两个逻辑库，A 和 B 库分别属于两个你的客户，这两个客户都要在自己建的库创建一个管理员账号，这个账号叫 admin，在他们创建这个用户后，失败了，因为在PG智能有一个用户叫admin,实际上不是的，PG支持 db_user_namespace,这个参数的主要意义是，可以在 /c database 后在每个数据库里面都可以建立用户，且这些用户的名字可能是一样的，但权限都是在自己的数据库内部而不是整体的。这样的设置非常适合多租户的数据库使用方式。

但是需要说明，这个参数是在PG 9.3之前有的，后面去掉了，所以这个参数可以帮助我们理解为什么PG是一个多租户的数据库系统，也可以从一个侧面了解曾经的PG的设想是多么的宏伟，在很早之前就有类似ORACLE的租户的想法。

剩下的还有一堆trace的参数，很少在PG的文章中有相关的介绍

5 trace_notify

在PG数据库中希望在日志中记录notify事件的详细信息，默认的时候这个参数是关闭，建议在一些新装的测试库，或者想更深入了解PG的工作中的一些内容，可以开启这个参数，但会造成日志变大。

6 trace_sort

跟踪查询排序（sort）执行的详细信息，默认是不开启的。在开启后，日志会记录详细的排序策略，使用的内存，以及是否内存无法处理，要通过磁盘来进行相关信息的处理。对于一些语句分析有需要的数据库系统可以考虑打开，但也会增加日志的量。

7 track_activities

跟踪数据库中正在执行的SQL语句，信息存储在pg_stat_activity视图中，默认是就是开启的因为不开启那么在pg_stat_activity 视图里面的query 就无法获得信息了，所以当你的pg_stat_activity的视图信息中query是null的话，去看看这个参数是否被off了。

8 track_activity_query_size

和上面的功能中query有关的，track_activity_query_size是针query字段中的可以存储的SQL语句的长度，单位是字节，默认1024字节，为什么要有这个值，在一些环境中，有的SQL写的比较大，如果不扩大这个部分，则无法抓取SQL，所以适当的在一些报表的服务器中将track_activity_query_size提高保证SQL不被截断。如 track_activity_query_size = 2048

9 track_counts

很多人在使用PostgreSQL的时候提出一个问题，在pg_stat_user_tables, pg_stat_user_indexes中将记录的Postgresql统计数据库访问信息，如表扫描次数，索引使用的次数等等都放到系统的视图中。所以这个参数默认是开启的。

10 track_functions

这个参数是将函数的或者存储过程的执行次数和时间的信息存储在pg_stat_user_functions视图内，默认是不开启的，这里有几个值 none , pl，all ,如果系统中并未有大量的存储过程或函数，是可以开启的，否则没有必要开启。

11 track_io_timing

在很多的文档中，都有提到过这个参数，track_io_timing,在正常的生产环境中都不建议使用这个参数，其中重要的原因是影响性能。但是从来没有说影响什么性能，track_io_timing主要的的作用是分析PG在执行语句时IO的消耗问题，打开会记录读取和写入磁盘所花费的时间，并在pg_stat_statements中记录IO相关的信息。这里就要提到获得精确的时间的消耗问题，从语句的执行到结束，不断的获得时间信息，若大量的SQL同时并发允许，则就成为系统运行的负担。

那么如果想使用这个参数，但不知道会不会影响可以看这个

[postgres@postgre14 ~]$ pg_test_timing -d 10
Testing timing overhead for 10 seconds.
Per loop time including overhead: 80.84 ns
Histogram of timing durations:
  < us   % of total      count
     1     92.64340  114602633
     2      7.33783    9077110
     4      0.00745       9216
     8      0.00010        128
    16      0.00049        600
    32      0.00232       2865
    64      0.00449       5558
   128      0.00308       3812
   256      0.00065        804
   512      0.00017        207
  1024      0.00001         17
  2048      0.00001          8
  4096      0.00000          5
  8192      0.00000          3
[postgres@postgre14 ~]$

这里我们看到运行pg_test_timing的结果是80.84ns,这里意思是单次在开启了track_io_timing，要消耗的时间，如果这个时间低于10则我们可以认为忽略，不影响系统，但如果超过或像我上面的值这么大，那么过多调用必然会影响CPU的性能。

所以不清楚的可以通过测试命令来进行测试，再觉得是否开启此参数。

12 track_wal_io_timing

这个参数和上面参数的意义相同，但是他是针对wal的日志部分，包含了wal的写入时间和wal的刷盘时间，在我们购买一款新的硬件，或者想对于云上的环境的系统的情况进行测试的时候，可以开启，这个参数是在PG16上增加的参数，信息回在pg_stat_wal的系统view中显示。

SELECT wal_write, wal_sync, wal_write_time, wal_sync_time
FROM pg_stat_wal;
 wal_write | wal_sync | wal_write_time | wal_sync_time
-----------+----------+----------------+---------------
  1234567  |   45678  |    2500.12 ms  |    500.45 ms

13 transaction_buffers

这个参数是从PG16开始的提供的，在越来越多使用PG数据库产品中的逻辑复制槽后，随着数据量的加大WAL_buffer的压力越来越大，这个参数就产生了transaction_buffers，通过这个参数来对大量的UPDATE的PG系统WAL_BUFFER减少压力。

14 subtransaxtion_buffers

这个参数在PG16被取消了，主要的原因是在早期的PG系统中，在存储过程中使用savepoint后，基于运行的存储过程需要的内存的大小不一，如果写死内存的大小，会存在运行中溢出内存的风险，在PG16解决了这个问题，这个参数被撤下，使用动态的方式来管理。

15 default_transaction_deferrable

SET default_transaction_isolation = 'serializable';
SET default_transaction_deferrable = on;

BEGIN TRANSACTION ISOLATION LEVEL SERIALIZABLE DEFERRABLE;

这个参数应该这些参数里面最冷门的，主要针对在事务运行中使用了SERIALIZABLE隔离级别的事务时减少事务和事务之间产生冲突的可能，具体原理就是延迟SERIALIZABLE事务与其他事务运行的时间差，延迟SERIALIZABLE事务的执行。

置顶

OceanBase 6大学习法--OBCA视频学习总结第六章

数据库的 4月1日愚人节，我没有被愚弄！

搞 PostgreSQL多才多艺的人--赵渝强《PG数据库实战派》

追逐太阳的男人--林春《金融数据库转型实战》

数据库的 4月1日愚人节，我没有被愚弄！

数据库界的“申公豹”，带云DBA走出--救生筏困境！

阿里云DTS 产品，你真让我出离愤怒，3年了病还没治好？？？

让数据先“活”起来，如何实现数据在企业中的最大价值

专访唐建法-从MongoDB中国第一人到TapData掌门人的故事

ETL 行业也够卷，云化ETL，ETL 软件不过了