第六章 清理过程
- 1. 概念
- 2. 并发清理
- 2.1 清理过程
- 2.1.1 第一部分：冻结处理
- 2.1.2 第二部分：移除死元组
- 2.2 可见性映射
- 2.3 冻结过程
- 3. 完整清理（FULL VACUUM）
1. 概念
清理（VACUUM）是一种维护过程，有助于PostgreSQL的持久运行。
两个主要任务：
1.删除死元组
为了删除死元组，清理过程有两种模式：并发清理（Concurrent Vacuum） 与完整清理（Full Vacuum）
并发清理：会删除表文件每个页面中的死元组，而其他事务可以在其运行时继续读取该表。
完整清理：不仅会移除整个文件中所有的死元组，还会对整个文件中所有的活元组进行碎片整理。而其他事务在完整清理运行时无法访问该表。
2.冻结事务标识
2. 并发清理
清理过程为指定的表，或数据库中的所有表执行以下任务。
1.移除死元组
- 移除每一页中的死元组，并对每一页内的活元组进行碎片整理。
- 移除指向死元组的索引元组。
2.冻结旧的事务标识（txid）
- 如有必要，冻结旧元组的事务标识（txid）。
- 更新与冻结事务标识相关的系统视图（pg_database与pg_class）。
- 如果可能，移除非必需的提交日志（clog）。
3.其他
- 更新已处理表的空闲空间映射（FSM）和可见性映射（VM）。
- 更新一些统计信息（pg_stat_all_tables等）。
2.1 清理过程
2.1.1 第一部分：冻结处理
- 扫描所有页面，定位死元组；如有必要，冻结过老的元组。
- 如果存在，移除指向死元组的索引元组。
2.1.2 第二部分：移除死元组
这一部分会移除死元组，并逐页更新FSM（空闲空间映射）和VM（可见性映射）
假设该表包含三个页面，这里先关注0号页面（即第一个页面）。该页面包含三条元组， 其中Tuple_2是一条死元组，如图6.1(1)所示。在这里PostgreSQL移除了Tuple_2，并重排剩余元组来整理碎片空间，然后更新该页面的FSM和VM，如图6.1(2)所示。 PostgreSQL不断重复该过程直至最后一页。
2.2 可见性映射
清理过程的代价高昂，因此PostgreSQL在8.4版中引入了VM，用于减小清理的开销。
VM的基本概念很简单。 每个表都拥有各自的可见性映射，用于保存表文件中每个页面的可见性。 页面的可见性确定了每个页面是否包含死元组。清理过程可以跳过没有死元组的页面。
图6.2展示了VM的使用方式。 假设该表包含三个页面，第0页和第2页包含死元组，而第1页不包含死元组。 表的可见性映射中保存着哪些页面包含死元组的信息。 在这种情况下，清理过程可以参考VM中的信息，跳过第一个页面。
2.3 冻结过程
冻结过程通常以惰性模式运行；但当满足特定条件时，也会以迫切模式运行。
- 在惰性模式下，冻结处理仅使用目标表对应的VM扫描包含死元组的页面。
- 迫切模式相则反，它会扫描所有的页面，无论其是否包含死元组，它还会更新与冻结处理相关的系统视图，并在可能的情况下删除不必要的clog。
3. 完整清理（FULL VACUUM）
虽然并发清理对于运维至关重要，但光有它还不够。比如，即使删除了许多死元组，也无法压缩表大小的情况。
图6.8给出了一个极端的例子。假设一个表由三个页面组成，每个页面包含六条元组。执行以下DELETE命令以删除元组，并执行VACUUM命令以移除死元组：
死元组虽然都被移除了，但表的尺寸没有减小。 这种情况既浪费了磁盘空间，又会对数据库性能产生负面影响。 例如在上面的例子中，当读取表中的三条元组时，必须从磁盘加载三个页面。
为了解决这种情况，PostgreSQL提供了完整清理模式。 图6.9概述了该模式。
1.创建新的表文件：见图6.9(1)
当对表执行VACUUM FULL命令时，PostgreSQL首先获取表上的AccessExclusiveLock锁，并创建一个大小为8 KB的新的表文件。 AccessExclusiveLock锁不允许任何其他访问。
2.将活元组复制到新表：见图6.9(2)
PostgreSQL只将旧表文件中的活元组复制到新表中。
删除旧文件，重建索引，并更新统计信息，FSM和VM，见图6.9(3)
复制完所有活元组后，PostgreSQL将删除旧文件，重建所有相关的表索引，更新表的FSM和VM，并更新相关的统计信息和系统视图。
