【发布时间】：2020-02-04 08:52:12
【问题描述】：
我在生产环境中继承了一个 PostgreSQL 数据库，其中包含一个大小约为 250 GB 的表。它只有大约一万行，我估计不超过 20 MB。
由于AUTOVACUUM 已在某个时间关闭，该表变得如此大。 （我知道这样做的原因。它将被重新激活并且原始问题已得到修复，因此这不是问题的一部分。）
我们的问题是许多查询需要很长时间。例如，SELECT count(*) FROM foo; 大约需要 15 分钟。
现在在考虑其他选项后，我想在桌面上运行VACUUM FULL。我尝试估计完成此操作所需的持续时间，以便计划维护窗口。
据我了解，VACUUM FULL 创建了一个新表，将所有活动元组复制到其中，并用此副本替换原始表。
我的估计是，此过程不会比在此表上进行上述简单查询所需的时间长很多，因为实时数据的总体大小和数量非常少。
您是否同意我对“VACUUM FULL”的运行时间的期望在某种程度上是现实的？如果没有，为什么不呢？
是否有估算VACUUM FULL 持续时间的最佳做法？
【问题讨论】：
-
@a_horse_with_no_name 不幸的是，由于“部分”托管环境，我们无法使用自定义扩展。我知道写入速度较慢，但我认为这对整体运行时间没有太大影响，因为需要写入的数据量相对较小。
-
@a_horse_with_no_name 但是如果他的估计是正确的，它需要读取 250GB 而只需要写入 20MB。写作可能比阅读慢，但不会慢 10,000 倍。
标签： sql postgresql postgresql-10 vacuum