前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >做事的有始有终,PostgreSQL Vacuum once and for all

做事的有始有终,PostgreSQL Vacuum once and for all

作者头像
AustinDatabases
发布2019-06-21 16:40:02
6610
发布2019-06-21 16:40:02
举报
文章被收录于专栏:AustinDatabasesAustinDatabases

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 更深层次的东西。

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2019-05-31,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 AustinDatabases 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
数据库
云数据库为企业提供了完善的关系型数据库、非关系型数据库、分析型数据库和数据库生态工具。您可以通过产品选择和组合搭建,轻松实现高可靠、高可用性、高性能等数据库需求。云数据库服务也可大幅减少您的运维工作量,更专注于业务发展,让企业一站式享受数据上云及分布式架构的技术红利!
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档