数据仓库的 DROP TABLE / TRUNCATE 方法是否需要 VACUUM FULL

Question

我们每周都会使用一系列更新数据仓库

TRUNCATE source_table1 
COPY source_table1 FROM [...]

...用于数据导入以及：

DROP TABLE IF EXISTS my_table
CREATE TABLE my_table AS SELECT [...]

用于表更新。

我们以 结束更新过程VACUUM FULL [VERBOSE] ANALYZE，因为正如文档所示，VACUUM应该在更新或删除大量元组时完成更新过程。在这里，由于所有表的份额为 100%，因此我们合理地认为VACUUM应该应用这一点。

正如我们看到 verbose 选项的输出，Postgresql 似乎没什么可做的，正如每个表VACUUMed 给出的那样：

INFO:  vacuuming "public.table345"
INFO:  "table345": found 0 removable, 9831703 nonremovable row versions in 62538 pages
DETAIL : 0 dead row versions cannot be removed yet.

我认为相反，这ANALYZE对于更新内部统计数据更有帮助。大多数表的行数为 10-100m。

但我们想知道在这种情况下是否VACUUM FULL真的VACUUM有必要？

（或者可能整个更新过程（DROP / CREATE TABLE AS）不是正确的方法？）

Answer 1

关于截断/复制的要点

不相关的注意事项，根据 WAL 级别，将TRUNCATE和包装COPY在同一事务中可能会更快，因为 WAL 将被跳过。此外，CTAS 将始终跳过大多数 WAL。

在最低级别上，可以安全地跳过一些批量操作的 WAL 日志记录，这可以使这些操作更快（参见第 14.4.7 节）。可以应用此优化的操作包括 源

• 创建表为
• 创建索引
• 簇
• 复制到在同一事务中创建或截断的表中

    BEGIN;
      TRUNCATE source_table1 
      COPY source_table1 FROM [...]
    COMMIT;

问题在于VACUUM FULL

1. 无需VACUUM FULL在新表上执行 a 操作。该表在这些事务中已经是新的，因此不需要像FULL以前那样重写它。也没有必要这样做，VACUUM因为 VACUUM 不会作用于可移动的行。当您运行时VACUUM FULL VERBOSE，您可以看到没有任何内容是可删除的，并且没有死行被删除。VACUUM FULL如果

   1. 您正在暂存INSERTS临时表，并将它们批量添加到脏表中。然后，它通常可以在流程结束时得到回报。
   2. 您正在UPDATE大批量运行，因为UPDATE会生成新行VACUUM，迫使稍后将旧行标记为死行。

2. 一个简单的ANALYZE就可以很好地工作。这将更新表上的统计信息。