Postgresql 分组查询速度非常慢

我的查询速度非常慢（~100分钟）。我省略了很多内部子节点，用后缀

…

HashAggregate  (cost=6449635645.84..6449635742.59 rows=1290 width=112) (actual time=5853093.882..5853095.159 rows=785 loops=1)
   Group Key: p.processid
   ->  Nested Loop  (cost=10851145.36..6449523319.09 rows=832050 width=112) (actual time=166573.289..5853043.076 rows=3904 loops=1)
         Join Filter: (SubPlan 2)
         Rows Removed by Join Filter: 617040
         ->  Merge Left Join  (cost=5425572.68..5439530.95 rows=1290 width=799) (actual time=80092.782..80114.828 rows=788 loops=1) ...
         ->  Materialize  (cost=5425572.68..5439550.30 rows=1290 width=112) (actual time=109.689..109.934 rows=788 loops=788) ...
         SubPlan 2
           ->  Limit  (cost=3869.12..3869.13 rows=5 width=8) (actual time=9.155..9.156 rows=5 loops=620944) ...
Planning time: 1796.764 ms
Execution time: 5853316.418 ms
(2836 rows)

上面的查询计划是对视图执行的查询，模式如下（简化）

我不明白的是为什么它使用位图索引扫描而不是索引扫描。从表面上看，应该只有788行需要比较？那不是更快吗？如果没有，我如何优化此查询

processid

是bigint类型并具有索引

---

完整的执行计划是。

您方便地在执行计划中省略了表的名称，但我假设嵌套的循环联接在

foo\u bar\u表r

和

foo\u bar\u表h

之间，子计划是处于

状态的

高执行时间是由子计划引起的，该子计划针对每个潜在连接结果执行，即788*788=620944次。620944*9.156占5685363毫秒

创建此索引：

CREATE INDEX ON process (typeid, processid, installationid);

然后运行
VACUUM
：

VACUUM process;

这将使您能够快速地只扫描索引。
对于这种双嵌套查询的速度很慢，我一点也不感到惊讶。您需要查看查询的每个部分并对其进行优化。另外，我想有一种更简单的方法来编写它，但是如果没有样本数据，就不能说更多了？内部查询别名为
q
？我认为它不会改变性能，但您可以。不，大部分时间都花在子计划2中。以下是整个查询计划的要点：我使用的是较低的postgres版本，不支持
include
选项。我可以继续创建这样的索引吗<代码>在流程上创建索引（installationid、typeid、processid）
？我已经修改了答案。
CREATE INDEX ON process (typeid, processid, installationid);

VACUUM process;