开头还是介绍一下群，如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, Oceanbase, Sql Server等有问题，有需求都可以加群群内有各大数据库行业大咖，CTO，可以解决你的问题。加群请联系 liuaustin3 ，在新加的朋友会分到2群（共1720人左右 1 + 2 + 3 + 4+5） 另欢迎 OpenGauss GAUSSDB的技术人员加入
PostgreSQL 的内容之前写上百篇，这里打算开一个系列，叫PostgreSQL难搞的事情，主要针对PostgreSQL中经常被问及的问题和一些导致这些问题深层次的原因的一个主题。这次的主题从PostgreSQL的vacuum 开始，
说到Vacuum 属于是几家欢喜几家愁的，一般发愁的都是那些PostgreSQL 业务繁忙的大库，并且经常出现业务高峰期的一些系统性能的波动。但大部分人都只关注Vacuum, autovacuum 而忽略了一些为什么会产生这样动作的原因，同时不少人对 aggressive vacuum 的是什么不了解，导致vacuum 和 aggressive vacuum 的问题搞不清，最终导致严重的问题。
首先vacuum 的由来这个问题需要反复的说，在我们进行多版本控制,MVCC multiversion concurrency control ,是产生PG vacuum的根源 mvcc主要目的就是提供在数据库访问中可以进行并发访问，并发访问则需要对于事务中的数据提供同一行数据，在不同时间中访问中的版本信息，而这些信息是集中式，还是分散式是两种数据库设计的不同。
在PostgreSQL中我们使用了分散式，也就是将所有的行的版本信息驻留在我们的数据表内，基于这样的处理方式，导致后续这些失效的版本行信息需要进行清理，而清理这些行的信息的过程称为vacuum,相对应的我们会有 vacuum 和 autovacuum的命令和相关的过程来进行相关的工作，而基于这样的形成方式，导致PostgreSQL 应对这部分工作并产生了一套与其他数据库截然相反的工作。
在工作中我们大概率会遇到以下的一些问题
1 回收不及时，触发数据库回卷，导致触发aggresive vaccum,或最终导致freezing boom 触发单用户模式。
2 触发Autovacuum进行回收与系统正在进行高耗能操作撞车，导致系统性能出现瓶颈影响正常业务
3 关于vacuum的命令和参数多每个版本都有新的东西的加入，变化多部分版本对于命令参数进行了改变，并且参数的细致程度高，大部分人无法进行有效配置和调配
所以基于这些问题，我们需要分几期来说这个问题，整体系统化的梳理，基于数据库设计产生的一些在PostgreSQL中的特殊的需求的问题。
本期是这个系列的第一篇，所以我们先从问题的起源来详细说一说，这里我们看下图，下面两个图清晰的展示了数据表中某行的数据产生新一个行版本和老版本行共存的过程，以及访问中通过老的行指向新的行的过程等。
必然在上一个版本的行在所有事务中都成为历史行后，会成为死行，死行就相当于其他数据库中UNDO 中需要被清理的数据信息。
基于MVCC的形成，PostgreSQL的每行上都会对于他是那个数据库库事务的归属进行标记，在这样的情况下，标记每行属于那个事务的数字，txid也有使用耗费光的情况，基于这个数字的大小为2的32次方，那么在回收这些txid 号的情况下，很有可能由于一些情况而无法对这些txid的号进行收回，而长时间无法收回这些txid的情况就会导致数据库产生 aggressive vacuum ,aggressive vaccum 。
导致aggressive vacuum 后最大的问题是，aggressive vacuum中的扫描工作，普通的vacuum本身并不会对数据表中每页的数据进行扫描，而aggressive vacuum 则是针对未冻结的数据页面全部扫描，扫描中会导致大表较长时间在进行整体的页面扫描，扫描期间的CPU 和IO 均会为此项工作服务，同时还会导致长时间针对这张表无法进行DDL操作。所以我们在工作中，都在尽力的避免发生 aggressive vacuum 的工作。
下面我们通过一个列子来进行展示，我们找到一张表，其中我们计算出他的相关的age 是 478
postgres=# SELECT c.oid::regclass as table_name,greatest(age(c.relfrozenxid),age(t.relfrozenxid)) as age
postgres-# FROM pg_class c
postgres-# LEFT JOIN pg_class t ON c.reltoastrelid = t.oid
postgres-# WHERE c.relkind IN ('r', 'm') and c.oid::regclass::varchar = 'time_test';table_name | age
------------+-----time_test | 478
(1 row)
然后我们针对这张表进行vacuum 的操作，然后我们在观察相关的这张表的age
postgres=# vacuum verbose time_test;
INFO: vacuuming "public.time_test"
INFO: table "time_test": found 0 removable, 1 nonremovable row versions in 1 out of 1 pages
DETAIL: 0 dead row versions cannot be removed yet, oldest xmin: 878875
0 pages removed.
Skipped 0 pages due to buffer pins, 0 frozen pages.
CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s.
VACUUM
postgres=#在我们对表进行vacuum后，发现表的age还是 478，并未有任何的变化。在我们改变命令后，针对这个表进行freeze 的操作后，我们在观察age的部分已经变为0.
postgres=# vacuum freeze verbose time_test;
INFO: aggressively vacuuming "public.time_test"
INFO: table "time_test": found 0 removable, 1 nonremovable row versions in 1 out of 1 pages
DETAIL: 0 dead row versions cannot be removed yet, oldest xmin: 878875
0 pages removed.
Skipped 0 pages due to buffer pins, 0 frozen pages.
CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s.
VACUUM
postgres=# SELECT c.oid::regclass as table_name,greatest(age(c.relfrozenxid),age(t.relfrozenxid)) as age
FROM pg_class c
LEFT JOIN pg_class t ON c.reltoastrelid = t.oid
WHERE c.relkind IN ('r', 'm') and c.oid::regclass::varchar = 'time_test';table_name | age
------------+-----time_test | 0
(1 row)
postgres=# SELECT
postgres-# oid::regclass::text AS table,
postgres-# age(relfrozenxid) AS xid_age,
postgres-# mxid_age(relminmxid) AS mxid_age,
postgres-# least(
postgres(# (SELECT setting::int
postgres(# FROM pg_settings
postgres(# WHERE name = 'autovacuum_freeze_max_age') - age(relfrozenxid),
postgres(# (SELECT setting::int
postgres(# FROM pg_settings
postgres(# WHERE name = 'autovacuum_multixact_freeze_max_age') - mxid_age(relminmxid)
postgres(# ) AS tx_before_wraparound_vacuum,
postgres-# pg_size_pretty(pg_total_relation_size(oid)) AS size,
postgres-# pg_stat_get_last_autovacuum_time(oid) AS last_autovacuum
postgres-# FROM pg_class
postgres-# WHERE not (relfrozenxid = 0)
postgres-# AND oid > 16384
postgres-# ORDER BY tx_before_wraparound_vacuum;table | xid_age | mxid_age | tx_before_wraparound_vacuum | size | last_aut
----------------------+---------+----------+-----------------------------+------------+---------test_t | 289 | 0 | 199999711 | 127 MB | collates | 253 | 0 | 199999747 | 56 kB | test_table | 234 | 0 | 199999766 | 40 kB | xcc.xcc | 210 | 0 | 199999790 | 0 bytes | pgbench_history | 14 | 0 | 199999986 | 0 bytes | pgbench_accounts | 14 | 0 | 199999986 | 13 GB | pgbench_branches | 14 | 0 | 199999986 | 112 kB | pgbench_tellers | 14 | 0 | 199999986 | 712 kB | bank | 3 | 0 | 199999997 | 40 kB | dba_autovacuum_table | 0 | 0 | 200000000 | 8192 bytes | time_test | 0 | 0 | 200000000 | 56 kB |
(11 rows)上面的脚本可以方便的查看当前的数据库中表中的AGE 以及发生回卷的计数器的数值。
在PostgreSQL 16 中针对vaccumdb 命令有了一些变化，我们把PG14 和PG16 的vacuumdb
我们清晰的看到有四个部分是不同的
1 --buffer-usage-limit=SIZE
2 --no-process-main
3 -n, --schema=PATTERN
4 -N, --exclude-schema=PATTERN
具体上我们可以对1 ，2 两个部分进行更细的研究
buffer-usage-limit 命令主要的意义,主要的目的还是针对具有大内存的主机，在进行vaccum的过程中，可以给与更多的内存，尽量对于大表进行快速有效的vacuum。相关范围在不开启和 128KB - 16G 之间进行设置。
--no-process-main 这个主要添加的参数是为了不进行表的vacuum 只对表中的toast进行vacuum。
参考：https://www.postgresql.org/message-id/08930c0b541700a5264e5fbf3a685f5a@oss.nttdata.com
