在共享计划中，索引扫描成本非常高（成本=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
2条答案
按热度按时间0wi1tuuw1#
索引扫描中报告的成本估计是对它是否运行到完成的估计。LIMIT节点随后降低该估计的费率，以说明（估计的）提前停止。
现在我认为这个查询是无害的，因为它看起来最终的成本是224.59只在CPU上，所以这不是一个CPU加载查询。
查询需要9秒钟。大多数人会认为这太慢了。当你有实际的时间盯着你的脸时，估计不准确不应该是一个安慰的原因。
ncgqoxb02#
我不太清楚你的问题是什么。
这个查询可以通过覆盖索引来加速：
该索引上的一系列range scans可以满足您的查询。