PG：查询计划器与random_page_cost

2021-03-05 10:09

查询计划器与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人参与

立即登录即可访问所有OFweek服务

忘记密码

其他方式

请输入评论内容...

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

暂无评论

图片新闻