Postgres中Drop表和Truncate表的速度差异

Question

我目前有一个程序，通过创建临时表、填充表，然后将该数据合并到主表中来插入数据库。然后放下桌子并重新做一遍。我想知道如果我只是截断而不是删除和创建，速度差异是多少。

Answer 1

DROP&CREATE稍微昂贵一些，因为除了删除物理表文件之外，它实际上还会从某些系统表（pg_class、pg_attribute、 ...）中删除行 - 并且稍后必须解析新CREATE TABLE命令等，而TRUNCATE仅删除表并开始新的表，保留目录条目。但对于简单表，尤其是临时表，差异可以忽略不计。它会变得更小，但如果您考虑ANALYZE到之后可能需要的额外内容TRUNCATE。话又说回来，无论如何你可能都需要它。看：

• 在 9.1 下仍建议使用常规 VACUUM ANALYZE 吗？

我想你的意思是“填满表格”COPY？一个成本更高的差异是在写入之前在单独的事务中创建一个普通表，因为在这种情况下，您会增加写入 WAL（预写日志）条目的额外（大量）成本CREATE。手册：TRUNCATE

COPY当在与较早的 命令或命令相同的事务中使用时速度最快。在这种情况下，不需要写入 WAL，因为如果发生错误，包含新加载数据的文件无论如何都会被删除。但是，此注意事项仅适用于非分区表，因为否则所有命令都必须写入 WAL。CREATE TABLETRUNCATEwal_levelminimal

大胆强调我的。在 Postgres 9.6 之前minimal一直是默认设置。wal_level从版本 10 开始，默认replica. 不影响临时表，临时表根本不写入 WAL。

您可能感兴趣CREATE TEMP TABLE ...ON COMMIT DELETE ROWS。
手册：

临时表中的所有行都将在每个事务块结束时被删除。TRUNCATE本质上，每次提交都会自动完成。当在分区表上使用时，它不会级联到其分区。

应该是最快的。但差异通常仍然很小。

Answer 2

DROP TABLE -- 移除/删除表

TRUNCATE——清空一个表或一组表，但保留其结构以供将来的数据使用。

如果您不打算再次使用该表，则可以使用DROP该表。

如果您打算再次使用该表，则需要TRUNCATE一个表

与根据您的情况进行功能正确的操作相比，速度差异微不足道。速度可能产生影响的唯一情况是您执行操作数百次。

因此，让我们考虑一下这种情况：如果您不再需要这几百个表，那么您不妨将它们删除，否则它们将保留在那里占用资源。

如果您要重用这些表，请截断它们，否则您将不得不重新创建它们。我猜想 TRUNCATE 比DELETE+CREATE.

检查此链接以获取更多信息：

PostgreSQL 文档：DROP

PostgreSQL 文档：截断