postgres truncate很慢

Question

在postgres 9.2（CentOS）中，TRUNCATE TABLE命令偶尔需要很长时间才能运行。有一次，截断一个有100K记录的表需要1.5个多小时，在其他情况下甚至更长。当我使用pgAdmin截断表时也会发生此问题。可能的原因是什么？以及如何提高截断性能？

服务器上有16GB内存，shared_buffers = 1536MB

Answer 1

TRUNCATE必须为要截断的表刷新shared_buffers，并且必须取消旧文件的链接，这对于ext3缓慢删除的文件系统来说可能很慢。

1.5小时非常极端，因为我们通常最多会说几秒钟。您很可能在桌面上有其他会话锁，阻止TRUNCATE继续进行。请参阅pg_catalog.pg_locks和pg_catalog.pg_stat_activity。

The PostgreSQL wiki article on lock monitoring应该有用。

另请参阅：Postgresql Truncation speed

Answer 2

尝试断开与数据库的所有其他连接。 我花了很长时间才截断58000条记录。

将我的postgres数据库与PyCharm DB Navigator断开连接后，开发服务器等总共需要118毫秒。

Answer 3

检查truncate是否被任何查询阻止

SELECT
    activity.pid,
    activity.usename,
    activity.query,
    blocking.pid AS blocking_id,
    blocking.query AS blocking_query
FROM pg_stat_activity AS activity
JOIN pg_stat_activity AS blocking ON blocking.pid = ANY(pg_blocking_pids(activity.pid));

如有必要，终止它 SELECT pg_terminate_backend(PID);

Answer 4

这只是我和我的团队发生的事情。我们正在使用Postgres 12，并使用Apache NiFi进行了一些处理。卡住了。

我们做了一个：

systemctl status postgresql-12

然后我注意到很多“ TRUNCATED Waiting”，我尝试尝试重新加载Postgres失败，然后又杀死了每个卡住的进程。

此后工作正常，我们能够重新启动作业，只花了不到一秒钟的时间。