POSTGRESQL 13 可以并行VACUUM INDEX 你知道对吧

POSTGRESQL 我们在大量的使用，但实话实话知识的更新永远是滞后的，VACUUM 是可以并行进行INDEX 的操作，这个事情是在 POSTGRESQL 13 的这个版本上被实现的。

实际上POSTGRESQL 经常被其他数据库专家攻击的部分，有2个。 一个是我们熟知的 BF 问题，一个就是经常被提到的 Vacuum 问题。如果POSTGRESQL 解决了这两个问题，则其他数据库专家对POSTGRESQL 的口诛笔伐将失去源泉。

为什么是POSTGRESQL 13,因为postgresql 从13的这个版本针对VACUUM 的操作提供了更多的有效管理的方法。今天就要提的是POSTGRESQL VACUUM 的并行索引整理的功能。

这里分为两个部门

1 参数调整

max_parallel_maintenance_workers ,这个命令主要的提高了  maintenance_workers 工作中使用并行方式的可能，这里包含了 create index , vacuum 中不带有full的选项。所以在有适当的maintenance_work_mem 的情况下，以及冲去的 max_work_processes 的情况下，还可以继续调整 maintenance_io_concurrency 的值来增加在进行如上操作中，进行并行的可能性。

实际上这些值需要进行测试和验证，以在实际的工作场景中获得更多的有效的工作性。

所以基于参数的调整中，我们针对VACUUM 命令的执行中的并行性有了更多的可能性。

在我们操作POSTGRESQL 对表进行vacuum 操作中可以自动添加新的参数来增加进行vacuum 的并行的可能性。如

通过上图可以看到 vacuum (parallel 4) t_test; 通过传统的vacuum 命令中添加PG 13 独有的 parallel + 并行数可以激活针对索引的并行整理的工作，实际上 VACUUM  ，autovacuum的工作中，一大部分的工作并不是针对表本身，而是索引消耗了大量的VACUUM 工作的时间。

所以PG13 在这个部分针对索引对VACUUM 工作中的消耗的问题，提出了并行的方式来进行处理。

那么我们可以做一个相关的测试，来看看打开和不打开并行的工作VACUUM 的工作时间之间的不同，以及在整理中对于性能的影响的问题。

这里我们产生一个大表，并针对这个表进行相关的VACUUM 手动的工作来看看并行是否对于整理VACUUM 有时间的节省。

这是一张5000万的表，我们针对表中的字段进行了索引的添加。同时我们还要针对这个表进行UPDATE 的操作，产生死的元组。

我们针对表进行UPDATE 操作

update t_test set name = '1',address = '222222' where id > 567800 and id < 9000000;

后面我们将针对这个表，持续使用这个UPDATE 的语句，来进行使用并行和不使用并行的VACUUM 操作的对比工作。

1  采用了 8个并发的方式来进行VACUUM 工作

上面的图是进行VACUUM 操作时的系统消耗，下面的图是工作的时间，这里28秒完成了 VACUUM 的操作。

才买我们调整线程数，看看降低一半会有什么情况发生，首先还执行刚才的UPDATE 语句，然后将并行索引优化的的参数从 8 降低到 4 .

操作中使用的时间变成  27秒，同时通过NMON 观察系统CPU 的消耗的图形。

可以说此时使用 8 核心还是 4 核心，之间的差距并不大。我们在将并发调整到 2 看看针对 8 和 4 有什么不同。

在将并行降低到 2 后，工作时间变为21秒，比 8 和 4 核心分别低了 7 秒和 6秒。 

那么我们继续将并行关闭，看看工作的时间和系统的负载是多少。

操作中整体的操作整体的时间为 58秒，对比之前并行的操作中，2个并行效果是最好的，对比不开并行和开了并行 2核心，时间消耗为 2倍。

这就证明开启并行，针对不开启并行的VACUUM 命令针对索引过多的POSTGRESQL 的表来说，是有帮助的。

在测试中，测试了几种不同的并行度其中主要包含这两个参数

 -j, --jobs=NUM    use this many concurrent connections to vacuum

-P, --parallel=PARALLEL_WORKERS use this many background workers for vacuum, if available

这里主要调节的是  -j   使用多少连接去进行vacuum   -P 多少并行的 works 针对索引同时进行vacuum操作。

下面是一个测试的列表的结果的数据

PG 的物理机  8 CORE  16G  

1  8 JOB  8 parallel  28 秒

2  4 JOB  4 parallel  27 秒

3  2 JOB  2 parallel  21 秒

4  1 JOB  1 parallel  58 秒

5  2 JOB  4 parallel  33 秒

6  1 JOB  2 parallel  21 秒

通过测试，发现针对 JOB 的调整对于索引较多的表，改善并不明显，而适当调整针对索引的并行，有利于缩短vacuum的过程。具体的命令可以使用外部的命令来进行批量的测试。

vacuumdb -d postgres -e -j 1 -P 2 -t t_test -v