对于数据库系统的并发控制，PostgreSQL采用MVCC(多版本并发控制)进行处理。这种机制有一个缺点，就是随着时间的推移，数据文件中积累的dead tuples会越来越多。怎么去清理这些dead tuples，这个时候就需要vacuum处理。

PostgreSQL系统的vacuum是一个例行性的维护过程，系统也会在启动服务时启动autovacuum守护进程对此进行维护，当然也有vacuum命令可以让用户进行手动执行vacuum操作。除了清理dead tuples，vacuum还有冻结事务ID的功能，因为现在PostgreSQL的事务ID只支持32位(大概40亿个事务)，当事务ID达到最大值后，它会重新从0开始，这时以前的事务都会变成“未来”的事务变得不可见。

下面主要介绍vacuum清理dead tuples的过程。 在清理dead tuples时，系统有两种处理方式：vacuum 和 vacuum full。主要区别在如下：

vacuum

vacuum full

只是把表中的dead tuples进行删除标记，并没有真正物理删除；vacuum过程中，可以正常访问数据表

物理删除表中的dead tuples，释放空间给操作系统；vacuum full过程中，表被锁定，不允许访问

Vacuum过程

vacuum的执行过程主要分为以下三步：

1. 清除dead tuples指向的index tuples

该过程中，vacuum会顺序扫描目标表，并构建一个dead tuples组成的list链表，该list链表会存储在maintenance_work_mem缓存中。然后vacuum根据dead  tuples list移除dead tuples指向的index。

2. 移除dead tuples，更新VM和FSM

这里的移除dead tuples只是标记为可重用该空间，并没有真正物理删除。所以vacuum清理表后，表的实际空间并没有减小。dead tuples在做移除标记后，vacuum会重新排列剩余的元组以进行碎片化整理。然后，需要更新目标表的VM(可见性映射文件)和FSM(空闲空间映射文件)。

3. 更新统计信息和相关系统表

最后，需要更新vacuum目标表的统计信息(以适应最新的查询优化)和相关系统表。

Vacuum Full过程

Vacuum Full和Vacuum最大的不同就是，Vacuum Full是物理删除dead tuples，并把释放的空间重新交给操作系统，所以在vacuum full后，表的大小会减小为实际的空间大小。其处理过程和vacuum大不相同，处理步骤如下：

1.  vacuum full开始执行时，系统会先对目标创建一个AccessExclusiveLock ，不允许外界再进行访问(为后面拷贝做准备)，然后创建一个表结构和目标表相同的新表。

2. 扫描目标表，把表中的live tuples 拷贝到新表中。

3. 删除目标表，在新表上，重新创建索引，更新VM， FSM以及统计信息，相关系统表等。

所以，vacuum full的本质是生成一个新的数据文件，然后把原有表的live tuples存放到该数据文件中。对比vacuum， vacuum full缺点就是在执行期间不能对表进行访问，由于需要往新表中导入live tuples数据，其执行效率也会很慢。优点是执行后，表空间只存放live tuples，没有冗余的dead tuples，在执行查询效率上会有所提高。

AutoVacuum守护进程

由于vacuum是数据库系统的一个例行性维护，所以系统启动后，会开启一个autovacuum守护进程专门对此处理。autovacuum清理进程一般用vacuum而避免使用vacuum full。理由是，vacuum尽管可以保持表的最小尺寸，但是如果表还有继续增长的空间，这么做就意义不大了，特别是对于频繁写入的表。而且vacuum在执行效率上也比vacuum full好。

上面所说的autovacuum进程是一个launcher进程，它不进行vacuum操作，它负责启动vacuum worker进程，然后由vacuum worker进程进行相应的vacuum和analyze操作。

autovacuum进程会在每autovacuum_naptime时间间隔内为数据库启动autovacuum worker进程。然后每个worker进程会检查数据库中的每一个表，在需要时执行vacuum或analyze操作。如果有N个数据库，则每 autovacuum_naptime/N秒将启动一个新worker进程，在同一时间只允许最多autovacuum_max_workers 个worker进程运行，如果有超过autovacuum_max_workers 个数据库需要被处理，下一个数据库将在第一个worker结束后马上被处理。