PostgreSQL 9.3.6 中针对小表的截断操作非常缓慢。

Question

PostgreSQL 9.3.6 中针对小表的截断操作非常缓慢。

5

在Postgres 9.3.6中，对于一个少于10行的表进行截断操作通常需要2-3分钟。在延迟期间，截断被卡在等待=f和状态=idle in transaction。

在线研究中，这个问题的标准答案是锁争用，但这里似乎不是这种情况。这是在一个仅用于CI测试的未加载CI主机上发生的。根据pg_stat_activity，截断是唯一正在运行的语句，并且根据pg_locks，没有未被授予的锁定，因此我认为截断没有被阻塞等待锁定。

此外，我已经检查了死锁错误的postgres日志，但没有发现任何错误。

（请注意，我们使用对10行进行截断，因为这个问题是在CI测试期间发生的--在正常生产操作期间，该表中有大约10^6行，因此截断是有意义的。这是一个工作中间表，在我们的ETL过程的每次运行之前都会被截断。）

我不确定接下来该怎么做--任何建议将不胜感激！以下是相关查询的输出：

warehouse=# select pid,usename,backend_start,xact_start,query_start,now()-query_start as wait_time,state_change,waiting,state,query from pg_stat_activity;
-[ RECORD 1 ]-+-----------------------------------------------------------------------------------------------------------------------------------------------
pid           | 25123
usename       | dev
backend_start | 2015-04-13 23:25:47.728267+00
xact_start    | 2015-04-14 00:23:39.969074+00
query_start   | 2015-04-14 00:23:39.969074+00
wait_time     | 00:00:00
state_change  | 2015-04-14 00:23:39.969081+00
waiting       | f
state         | active
query         | select pid,usename,backend_start,xact_start,query_start,now()-query_start as wait_time,state_change,waiting,state,query from pg_stat_activity;
-[ RECORD 2 ]-+-----------------------------------------------------------------------------------------------------------------------------------------------
pid           | 5288
usename       | fk-etl
backend_start | 2015-04-14 00:21:20.913133+00
xact_start    | 2015-04-14 00:21:20.921312+00
query_start   | 2015-04-14 00:21:20.92142+00
wait_time     | 00:02:19.047654
state_change  | 2015-04-14 00:21:20.928318+00
waiting       | f
state         | idle in transaction
query         | TRUNCATE TABLE foo_schema.foo


warehouse=# select * from pg_locks;
warehouse=# SELECT relation::regclass as object, mode,granted,pid FROM pg_locks;
-[ RECORD 1 ]---------------------------------------------------------------------------
object  | 
mode    | ExclusiveLock
granted | t
pid     | 5288
-[ RECORD 2 ]---------------------------------------------------------------------------
object  | pg_locks
mode    | AccessShareLock
granted | t
pid     | 25123
-[ RECORD 3 ]---------------------------------------------------------------------------
object  | 
mode    | ExclusiveLock
granted | t
pid     | 25123
-[ RECORD 4 ]---------------------------------------------------------------------------
object  | foo_schema.foo_compound_idx
mode    | AccessExclusiveLock
granted | t
pid     | 5288
-[ RECORD 5 ]---------------------------------------------------------------------------
object  | foo_schema.foo
mode    | ShareLock
granted | t
pid     | 5288
-[ RECORD 6 ]---------------------------------------------------------------------------
object  | foo_schema.foo
mode    | AccessExclusiveLock
granted | t
pid     | 5288
-[ RECORD 7 ]---------------------------------------------------------------------------
object  | foo_schema.foo_pkey
mode    | AccessExclusiveLock
granted | t
pid     | 5288
-[ RECORD 8 ]---------------------------------------------------------------------------
object  | pg_toast.pg_toast_10043463
mode    | ShareLock
granted | t
pid     | 5288
-[ RECORD 9 ]---------------------------------------------------------------------------
object  | pg_toast.pg_toast_10043463
mode    | AccessExclusiveLock
granted | t
pid     | 5288
-[ RECORD 10 ]--------------------------------------------------------------------------
object  | pg_toast.pg_toast_10043463_index
mode    | AccessExclusiveLock
granted | t
pid     | 5288
-[ RECORD 11 ]--------------------------------------------------------------------------
object  | 
mode    | ExclusiveLock
granted | t
pid     | 5288

- jaegard

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Craig Ringer · Accepted Answer

state         | idle in transaction
query         | TRUNCATE TABLE foo_schema.foo

TRUNCATE已完成，会话正在等待下一条语句或COMMIT。根据目前提供的信息，这似乎是一个应用程序方面的问题，但无法确定具体情况。