PostgreSQL 的 Vacuum已经说了2期了，本期的做一个了解，因为Vacuum  很重要，所以必须的深入理解，然后才能对这个事情做一个了解。

在这一行数据已经的xmax已经有值了，我可以认为这个数据可以被清除了，这里我们叫元组。而这些死了的元组，需要在FSM （一句话解释什么是FSM，FSM 就是数据页中标记那些是可用空间，那些不是可用空间，这里需要回收空间，将FSM 中标记那些死的元组的空间可以使用），而实际上 Vacuum 就是要将这些可以重用的空间，更新到 FSM文件中。

和我们的想象不同，将这些空间回收，并不会阻塞其他的数据操作，这应该是一个good sound， 至少空间的重新标记和在利用以及扫描等等都不会影响其他这些食物对这个表的访问和使用。

这里我们还是建立一个新表，并且插入10条数据

这里删除了三条数据，这里查看，t_max已经有了相关的号，说明这三个行已经是死tumple

这里将数据进行了 vacuum 在次查看表，这里面的数据已经空出来了。

到这里，可能有人会问，到底postgresql 什么时候可以将已经废弃的空间还给磁盘，这里我们做两个实验。

1 我们将所有的表的数据删除后，在进行数据的vacuum 

我们对比一下这个表的存储空间的变化，可以明显的看到vacuum后，磁盘的空间已经释放给了系统。

实验2 我们插入大量的数据，并且数据也开始疯狂的在磁盘中扩展自己的空间

大家可以对比数据页，已经从8K涨到了16K，这里我们删除了67条记录，而这些记录有一些问题就是，他们都先前插入的数据，而不是后面插入的数据

我们可以看到数据页中的数据在前面已经空了，但空间在vacuum 后并没有收缩。

这里我们开始删除后面的一些比较大的数据，看看有什么状况

从这里我们可以看出，后面的数据基本上删除光了，只留下了中间的一条数据，而在vacuum 后，在查看文件的情况。

在回收空间后，我们可以看到的确数据页已经从16K 收缩到 8K了，而FSM 文件和  VM 文件并没有变化

而FSM 文件的作用就是标记数据文件的中的空闲空间，而VM 文件就是每个数据库设置一个标示为，标记数据库中是否存在需要清理的行。

这里我们还有一个命令，vacuum full 命令，执行这个命令后，所有的空闲空间就会进行回收，回收后会将空间释放给磁盘空间。

我们可以看到在系统中执行了 vacuum full,系统的文件已经回收，FSM VM 文件都不在了，而在查看数据页中也发现其中剩余的数据还是存在的。

至此，虽然没有特别的深入vacuum ，还是在皮毛的阶段，并且也没有说明vacuum函数等等，所以，在继续领会一段postgresql 数据库后，可以在返回来继续研究vacuum 更深层次的东西。