小编Kev*_*Kev的帖子

设置

我有一个如下所示的批量插入功能set_interactions(arg_rows text)：

with inserts as (
    insert into interaction (
        thing_id,
        associate_id, created_time)
    select t->>'thing_id', t->>'associate_id', now() from
    json_array_elements(arg_rows::json)  t
    ON CONFLICT (thing_id, associate_id) DO NOTHING
    RETURNING thing_id, associate_id
) select into insert_count count(*) from inserts;

-- Followed by an insert in an unrelated table that has two triggers, neither of which touch any of the tables here (also not by any of their triggers, etc.)

（我这样包装它是因为我需要计算实际插入的数量，而没有“假行更新”技巧。）

该表interaction有：

1. 只有一个约束：多列主键 (thing_id, associate_id)
2. 没有索引
3. 只有一个触发器：插入后，对于每一行。

触发器执行以下操作：

DECLARE …

（这篇文章的后续内容：当我在子查询中 ORDER BY 时，为什么我的 PostgreSQL 表达式索引没有被使用？）

PostgreSQL 9.5。

我不能透露全部细节，但table有 22 列和 5 个索引：

1. 主键 ('pk'), text(btree)
2. 另一个text（btree）
3. 一个timestamp with time zone（btree）
4. 一个tsvector（杜松子酒）
5. 我最新的一个bigint（btree）

（从上一篇文章你知道我试图避免创建这个额外的列，只是使用表达式索引——将两integer列加在一起——没有成功。bigint这里的列可能只是“整数”，但我做了一个创建它时出错；添加列、填充它并重新编制索引花了大约一个小时，所以我希望这不相关，但要提及它以防万一。）

除了tsvector.

以下查询都只需要 12ms 并且只使用一个Index Scan：

1. SELECT pk FROM table ORDER BY pk DESC LIMIT 10
2. SELECT pk FROM table ORDER BY text_column DESC LIMIT 10
3. SELECT pk FROM table ORDER BY timestamp_column DESC LIMIT 10 …

这些是我的设置：

根据文档，据我所知，这种设置组合以及statement_timeout值 3600000应该意味着长达一小时的查询超时，并且在此之前，它们和任何其他超过 ~214ms 的内容都应该产生 EXPLAIN 输出在日志中。但他们不是。

1. shared_preload_libraries当我检查时已经auto_explain默认包含。
2. 上述参数应用于服务器。
3. 应用参数后我重新启动了实例。
4. 我的后端报告了一个事件canceling statement due to statement timeout（仅在我设置后才开始发生statement_timeout），但日志中没有任何内容（根本没有，更不用说在报告的时间附近）显示除 xlog 启动和停止之外的任何内容。

还可能缺少什么？