订阅
纠错
加入自媒体

PG:查询计划器与random_page_cost

2021-03-05 10:09
yzsDBA
关注

查询计划器与random_page_cost

本周小贴士比较奇怪,基于我们今天遇到的一个问题。将简讯的链接存储到一个简单数据库中:

CREATE TABLE links (

 uid CHAR(60) PRIMARY KEY,

 data TEXT,

 timestamp INT

CREATE INDEX idx_trgm ON links USING GIN (data gin_trgm_ops)

当然,这个设计比较烂。但仅供内部使用,我只是一个粗略的想法原型。数据是一个包含json(I know, I know...)的文本,以同样可怕的方式检查链接的存在:

SELECT * FROM links WHERE data ILIKE '%whatever we want%' LIMIT 1;

在低容量下运行很好,但查询时间偶尔会超过300ms,很好奇这是为啥?

执行EXPLAIN ANALYZE后,发现PG根本没使用GIN索引,而是使用了全表扫描。但是如果去掉LMIT 1,查询将使用索引,执行只需要5ms。为什么PG会忽略索引?

PG的查询规划器并不是真正基于人们做一些荒唐的事情。比如使用ILIKE进行全表扫描,关心的是走索引快还是全表扫描快。变量random_page_cost用于决定使用索引的代价是否值得,或者和seq_page_cost合作使用。

这种情况下,索引扫描是值得的,但是查询规划器不同意。因为看起来很简单的LIMIT 1,只找到一个结果就可以停止。并继续进行全表扫描。

SET random_page_cost = 1;

EXPLAIN ANALYZE SELECT * ... LIMIT 1;

   [see the index being used]

SET random_page_cost = DEFAULT;    

EXPLAIN ANALYZE SELECT * ... LIMIT 1;

[see the index NOT being used]

除了明显的“修复那个糟糕的模式”,看看PG会做什么,如果觉得索引扫描和顺序扫描比代价低。因此如果最终得到的查询使用索引,那么有必要尝试一下,通过EXPLAIN ANALYZE分析。

声明: 本文由入驻维科号的作者撰写,观点仅代表作者本人,不代表OFweek立场。如有侵权或其他问题,请联系举报。

发表评论

0条评论,0人参与

请输入评论内容...

请输入评论/评论长度6~500个字

您提交的评论过于频繁,请输入验证码继续

暂无评论

暂无评论

    人工智能 猎头职位 更多
    扫码关注公众号
    OFweek人工智能网
    获取更多精彩内容
    文章纠错
    x
    *文字标题:
    *纠错内容:
    联系邮箱:
    *验 证 码:

    粤公网安备 44030502002758号