设置

我在基于 SSD 的四核虚拟专用服务器 (VPS) 和 Debian Linux (8) 上运行 PostgreSQL 9.4.15。相关表有大约 200 万条记录。

记录经常被插入，甚至更频繁地（不断——至少每隔几秒钟）更新一次。据我所知，我已经为这些操作准备了所有适当的索引，以便快速执行，而且绝大多数时间它们确实会立即执行（以毫秒为单位）。

问题

然而，每隔一小时左右，其中一个UPDATE查询就会花费过多的时间——比如 10 秒或更长时间。当这种情况发生时，它通常就像“一批”被“阻塞”的查询，几乎同时终止。就好像其中一个查询或其他一些后台操作（例如，真空）正在阻止它们。

架构

表 ,items有很多列，但我认为以下是唯一可能与问题相关的列：

• id INTEGER NOT NULL （首要的关键）
• search_vector TSVECTOR
• last_checkup_at TIMESTAMP WITHOUT TIME ZONE

这些是相关的索引：

• items_pkey PRIMARY KEY, btree (id)
• items_search_vector_idx gin (search_vector)
• items_last_checkup_at_idx btree (last_checkup_at)

可能的罪魁祸首

最后，当pg_stat_activity我的日志文件中发出“连接泄漏”警告时，在组装了一个小脚本以转储（所有活动 Postgres 连接/查询的列表）的内容后，我缩小了可能的罪魁祸首查询/列（假设问题不是外部的，比如行为不端的 VPS）。粗略地说，这些查询似乎一次又一次地出现：

• UPDATE items SET last_checkup_at = $1 WHERE items.id = 123245
• UPDATE items SET search_vector = [..] WHERE items.id = 78901

这些略有解释，但我真的怀疑缺少任何相关内容。偶尔也会出现其他查询（在其他表上），但这些查询通常看起来只是“不走运”而被卷入其中。

现在，即使第一个查询（设置last_checkup_at …