Postgres Index drop 查询性能

Question

SELECT T.id_task,
        T.group,
        A.type
FROM TASK T
  JOIN ACTION A ON T.id_task = A.id_task

WHERE T.dt_inc BETWEEN 1511146800000 AND 1511492399999
  AND A.dt_scheduled BETWEEN 1511146800000 AND 1511492399999
  AND A.id_action > ( SELECT MIN(id_action) FROM ACTION WHERE T.id_task = id_task AND type <> 'TRANSFER' )

原来的查询要大得多，但有问题的部分就在这里。

仅使用 (task.dt_inc, action.dt_scheduled) 需要一分钟，但是如果我 DROP INDEX action_dt_scheduled，执行时间会下降到一秒，仅使用 (task) 的结果相同.dt_inc, action.id_task ) 索引。

• 为什么索引的表现如此糟糕？
• 我可以忽略这个索引而不删除它吗？

我重新创建了索引 DROP > CREATE，我使 REINDEX wath 应该与重新创建相同，我现在该怎么办？

编辑：

我试图得到慢查询的解释，但这不再慢了，表的 ANALYZE 和 REINDEX 已经解决了这个问题。

Answer 1

有更多原因导致使用索引而不是没有它时性能会更差：

1. 错误估计 - 使用索引时，使用随机 io。随机 io 通常比 seq 扫描慢得多 - 但如果索引选择表的一小部分，那么它是可以接受的。但是当 planner 对结果的估计不好时，尽管 seq 扫描更好，但可以使用索引。您可以通过EXPLAIN ANALYZE query 命令查看估算值。

2. 膨胀的索引 - 如果长时间未重新索引索引，则索引状态可能会很糟糕 - 那么索引的访问和使用可能会很慢。

3. 错误大小的effective_cache_size 参数 - 当此参数不准确或不安全时，索引页可以从 RAM 推送堆（表）页。在这种情况下，页面缓存（共享缓冲区）不稳定 - 您可以使用 pg_buffercache 扩展名检查共享缓冲区的稳定性。太低的shared_buffers 也会有类似的效果。