为什么在查询中使用 MAX 函数会导致 postgresql 性能问题？

Question

我有一个包含三列 time_stamp、device_id 和 status s.t status 的表格是 json。 time_stamp 和 device_id 列也有 index。我需要获取不为空的 id 1.3.6.1.4.1.34094.1.1.1.1.1 的最新状态值。

您可以使用下面的 MAX 找到以下命令 With 和 Without 的查询执行时间。

使用 MAX 查询：

SELECT DISTINCT MAX(time_stamp) FROM device.status_events WHERE 
(device_id = 7) AND
   (status->'1.3.6.1.4.1.34094.1.1.1.1.1' != '{}');

不带 MAX 的查询：

SELECT DISTINCT time_stamp FROM device.status_events WHERE 
(device_id = 7) AND
   (status->'1.3.6.1.4.1.34094.1.1.1.1.1' != '{}');

第一个查询大约需要 3 秒，第二个查询只需 3 毫秒，有两个不同的计划。我认为两个查询应该有相同的查询计划，为什么它在计算 MAX 时不使用 index？如何提高首次查询的运行时间？

PS我使用的是 postgres 9.6（dockerized 版本）。

这也是表定义。

-- Table: device.status_events

-- DROP TABLE device.status_events;

CREATE TABLE device.status_events
(
  time_stamp timestamp with time zone NOT NULL,
  device_id bigint,
  status jsonb,
  is_active boolean DEFAULT true,
  CONSTRAINT status_events_device_id_fkey FOREIGN KEY (device_id)
      REFERENCES device.devices (id) MATCH SIMPLE
      ON UPDATE NO ACTION ON DELETE CASCADE
)
WITH (
  OIDS=FALSE
);
ALTER TABLE device.status_events
  OWNER TO monitoring;

-- Index: device.status_events__time_stamp

-- DROP INDEX device.status_events__time_stamp;

CREATE INDEX status_events__time_stamp
  ON device.status_events
  USING btree
  (time_stamp);

Answer 1

您向我们展示的索引无法生成您向我们展示的第一个计划。使用该索引，计划必须为 jsonb 列应用过滤器，但事实并非如此。所以索引必须是部分索引，并且在索引级别应用过滤器，以便计划中不需要它。

PostgreSQL 是使用最大查询的索引，它只是不是您想要的索引。

您所有的 devide_id=7 都必须具有低时间戳，但 PostgreSQL 不知道这一点。它认为通过沿着timestamps索引走下去，它会很快找到一个device_id=7，然后就完成了。但相反，它需要遍历索引的一大块才能找到这样的行。

您可以通过将聚合表达式更改为以下内容来强制它远离“错误”索引：

MAX(time_stamp + interval '0')

或者您可以改为构建一个更量身定制的索引，计划者将选择该索引而不是具有虚假吸引力的索引：

create index on device.status_events (device_id , time_stamp) 
    where status->'1.3.6.1.4.1.34094.1.1.1.1.1' != '{}';

Answer 2

我相信这应该会产生一个更好的计划

SELECT time_stamp FROM device.status_events WHERE 
(device_id = 7) AND
   (status->'1.3.6.1.4.1.34094.1.1.1.1.1' != '{}')
ORDER BY timestamp DESC
LIMIT 1

让我知道这对你有什么作用。