PostgreSQL: 估计VACUUM FULL持续时间

6
我继承了一个生产环境中的 PostgreSQL 数据库,其中有一张表大小约为 250 GB。它只有大约一万行活跃数据,我估计不超过 20 MB。
由于某些原因,AUTOVACUUM 在某个时间被关闭,导致该表增长到如此庞大的规模。(我知道为什么会这样做。它将重新激活,并且已经修复了原始问题,因此这不是问题的一部分。) 我们的问题在于许多查询需要很长时间。例如,SELECT count(*) FROM foo; 大约需要 15 分钟。
现在,在考虑其他选项之后,我想在该表上运行 VACUUM FULL。我尝试估计完成所需的时间,以便可以计划维护窗口。
据我了解,VACUUM FULL 创建一个新表,将所有活动元组复制到其中,并用此副本替换原始表。
我的估计是,由于活动数据总体上的大小和数量相对较小,因此此过程所需的时间不会比上述简单查询在该表上执行的时间长得多。
您是否认为我的“VACUUM FULL”运行时间期望值是合理的?如果不是,请说明原因。
有没有估算 VACUUM FULL 所需时间的最佳实践?

@a_horse_with_no_name 很遗憾,由于“部分”受控环境的限制,我们无法使用自定义扩展。我知道编写速度较慢,但考虑到需要编写的数据量相对较小,因此我认为这不会对整体运行时间产生重大影响。 - dajood
1
@a_horse_with_no_name 如果他的估计是正确的,那么它需要读取250GB但只需要写入20MB。写入可能比读取慢,但不会慢10,000倍。 - jjanes
1个回答

6

唯一可靠的估计是在类似的机器上恢复文件系统备份并进行测试。这就是我建议的。

持续时间不仅取决于大小,还取决于膨胀量:如果真实数据较少,则速度会更快。

话虽如此,我建议留出2小时的维护时间窗口,这对于任何除非非常有问题的硬件都足够了。


2
维护窗口为期2小时,结果足够了。VACUUM FULL花费了72分钟。之后,表的大小为19 MB。谢谢 :) - dajood

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接