开头还是介绍一下群，如果感兴趣polardb ,mongodb ,mysql ,postgresql ,redis 等有问题，有需求都可以加群群内有各大数据库行业大咖，CTO，可以解决你的问题。
最近在整理VACUUM 相关知识的时候，发现一个问题对于 vacuum_freeze 的3个参数的概念掌握的不牢固，那么只能进行恶补了。本次的三个参数是
vacuum_freeze_min_age
vacuum_freeze_table_age
autovacuum_freeze_max_age
——————————————————————————————
我看看下图，下图中的一个圆是有缺口的，并且缺口的位置一直在变化，vacuum_freeze_min_age 就是这个缺口的 弧长。这个参数是针对表的，对于表，想到这里，根据图，大家应该会提出第二个问题，
图中的 A 和 B 两个位置，在PG的数据库中代表了什么
通过下图我们就可以很清晰的来理解 A B 两个点是从哪里来的 首先说A点，A点是来自于。
下面先简单说一下过程，我们查询了pgbench_tellers 的表，然后我们查看了xmin, xmax 两个部分，对于这个表倒排我们发现当前已经使用的事务号在这个表上已经到了 1199，查询了这个表的relfrozenxid 数值是 1046 ，那么我们做了一次 vacuum freeze ，然后在查看 relfrozenxid 的值是1200
实际上我们运行了vacuum freeze 的时候是将 vacuum_freeze_min_age 视为0 ，在运行的时刻，会将此表的事务ID 全部回收。
而这个参数设置的大小有关于，系统的性能的问题，设置较大会导致一次较大的回收扫描，消耗 IOPS 会较大，设置较小，会频繁在autovacuum上进行事务ID 的冻结操作。
普通的vacuum 使用visibility map来快速定位哪些数据页需要被扫描，只会扫描那些脏页，其他的数据页即使其中元组对应的xmin非常旧也不会被扫描。而在freeze的过程中，我们是需要对所有可见且未被all-frozen的数据页进行扫描，这个扫描过程PostgreSQL 称为aggressive vacuum。
何时进行aggressive vacuum 这个就是我们要说到的第二个参数vacuum_freeze_table_age ，vacuum_freeze_table_age 这个参数默认是1.5亿，最大值是20亿，
我们下面做一个关于 table age的例子，我们首先查看当前的事务的ID
postgres=# select * from txid_current();
txid_current
--------------
1200
(1 row)然后我们针对当前的所有的数据库的 age 进行检测，
postgres=# SELECT datname, age(datfrozenxid) FROM pg_database ORDER BY 2 DESC LIMIT 20;
datname | age
-----------+-----
template1 | 475
template0 | 475
postgres | 162
dvdrental | 92
(4 rows)最后我们针对某个数据库中的表进行 age的检测
dvdrental=# \c postgres
You are now connected to database "postgres" as user "postgres".
postgres=# SELECT c.relname as table_name, c.relkind as type, age(c.relfrozenxid) as age, c.relfrozenxid FROM pg_classgbench%';
table_name | type | age | relfrozenxid
------------------+------+-----+--------------
pgbench_accounts | r | 144 | 1057
pgbench_branches | r | 157 | 1044
pgbench_history | r | 156 | 1045
pgbench_tellers | r | 1 | 1200
(4 rows)
那么当这些age 达到我们在参数vacuum_freeze_table_age 中设置的值的情况下，就会发生 aggressive vacuum. 那么发生了 av 的情况下，当时的系统的消耗会较大，所以在PG的数据库运行维护中，是可以在非业务时间段，对一些特殊的表，进行事务ID的回收。
回收的命令很简单，在vacuum中加入 freeze 就可以对表或对整体的数据库进行事务ID的回收，降低 age. 从下图可以看出，在做完整体数据库的ID freezen 后，数据库postgres 的 age 已经降低到 0 。
最后说说 autovacuum_freeze_max_age，autovacuum_freeze_max_age 的主要作用是从全局来进行控制，对于全局的事务ID ，进行判断，当最新的和最旧的事务ID之间差距超过设置的值，则会强制进行事务ID的回收工作。
这里会一般会产生两个问题
1 vacuum_freeze_table_age 的值怎么设置，上面提到 FREEZN的操作是非常消耗IOPS的，因为他要针对页面进行扫描，所以vacuum_freezn_table_age的值，必须小于 autovacuum_freeze_max_age ，否则将起不到减少页面扫描的作用，但如果将vacuum_freeze_table_age 编辑的太小的情况下，将频繁产生 aggressive vacuum ,影响系统的性能。
2 vacuum_freeze_table_age 与 autovacuum_freeze_max_age 之间的值应该怎么设置，是否有一些官方的建议
从源代码中可以看到源代码中，强制对于 vacuum_freeze_table_age 中的值进行限制，限制的方式是， vacuum_freeze_table_age 的值，或者说table age 不能大于 autovacuum_freeze_max_age 的 0.95倍，从源代码也证明了，vacuum_freeze_table_age 必须要比 autovacuum_freeze_max_age 小。
到此为止，对于这三个参数的关系，以及相关的关联性我又重新的梳理和学习。
——————————————————————————————
本期继续写写自己的爱好，上次说了不能惹的德国大众高尔夫，这期说说国产钢炮也是中国汽车工业之光的领克03。在没这个车出现之前，中国的汽车工业在钢炮这个层面是 0 ，大多国产车就是低廉和没有性能的代名词，但在吉利收购了沃尔沃后，这一切就不一样了，领克作为国产汽车的一个系列，成为高端和高品质的代名词，尤其领克系列中的 03 03+ 03+CYAN , 填补了国产车钢炮的空白。
在马路上你或许经常见到 领克03 或 03+的汽车，见谁蹦谁的场面，什么奥迪，宝马，奔驰，都不含糊，最快的03+ CYAN已经可以 5.7秒破百，03 +的马力，已经到了 254 匹，这款车带有博格华纳的 4驱系统，起步很稳的领克03+ 是家用，赛用的结合，普通的03车型的马力也有190匹，同时据传，即将研发的 领克03 ++ TCR 将要达到350匹，将成为中国性能车之光，暴打一众欧洲超跑也不是没有可能。
另外领克 03+ CYAN 就是下面这个图中的车，是非改装车，也就是从4S店你买到就是这个样子，带有全碳纤维的可调整的尾翼，下唇，四驱，以及机械可调的10段避震，百公里加速 5.7秒，20多万就可以买到跑车的水准，你还要什么自行车，开上他，就俩字，刺激，三字真拉风
