为什么Postgresql解释开销在限制和结果阶段较低,但在索引扫描阶段较高

64jmpszr  于 2023-02-22  发布在  PostgreSQL
关注(0)|答案(2)|浏览(120)

在共享计划中,索引扫描成本非常高(成本=0.56..696715.50
但是限制(成本=0.56..224.59)非常低
依此类推结果成本结果(成本=224.59..224.60行=1宽度=8)
为甚么呢?
现在我认为这个查询是无害的,因为它看起来最终的成本是224.59只在CPU上,所以这不是一个CPU加载查询。
Postgresql版本是14。

explain analyze 
select min(ticketenti0_.created_at) as col_0_0_
  from ticket ticketenti0_
 where ticketenti0_.status=0
   and ticketenti0_.is_spam_ticket='false'
   and ticketenti0_.portal_id=0000
   and (ticketenti0_.group in (14 , 15 , 868 , 15 , 868 , 14));

查询计划

Result  (cost=224.59..224.60 rows=1 width=8) (actual time=9275.462..9275.464 rows=1 loops=1)   
InitPlan 1 (returns $0)     
->  Limit  (cost=0.56..224.59 rows=1 width=8) (actual time=9275.460..9275.461 rows=0 loops=1)           
      ->  Index Scan using idx_ticket_created_at_status_portal_id_group on ticket ticketenti0_  
           (cost=0.56..696715.50 rows=3110 width=8) (actual time=9275.458..9275.458 rows=0 loops=1)                 
          Index Cond: ((created_at IS NOT NULL) AND (status = 0) AND (portal_id = 0000))                 
          Filter: ((NOT is_spam_ticket) AND (group = ANY ('{14,15,868,15,868,14}'::bigint[])))                 
          Rows Removed by Filter: 148605

Planning Time: 0.926 ms
Execution Time: 9275.498 ms
0wi1tuuw

0wi1tuuw1#

索引扫描中报告的成本估计是对它是否运行到完成的估计。LIMIT节点随后降低该估计的费率,以说明(估计的)提前停止。
现在我认为这个查询是无害的,因为它看起来最终的成本是224.59只在CPU上,所以这不是一个CPU加载查询。
查询需要9秒钟。大多数人会认为这太慢了。当你有实际的时间盯着你的脸时,估计不准确不应该是一个安慰的原因。

ncgqoxb0

ncgqoxb02#

我不太清楚你的问题是什么。
这个查询可以通过覆盖索引来加速:

CREATE INDEX idx_status_spam_portal_group_created
       ON ticket USING BTREE
       (status, is_spam_ticket, portal_id, group, created_at);

该索引上的一系列range scans可以满足您的查询。

相关问题