查询计划器与random_page_cost

PG小贴士 专栏收录该内容
11 篇文章 65 订阅 ¥99.00 ¥9.90

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

EXP

  • 0
    点赞
  • 2
    评论
  • 0
    收藏
  • 一键三连
    一键三连
  • 扫一扫,分享海报

相关推荐
©️2020 CSDN 皮肤主题: 博客之星2020 设计师:CY__ 返回首页
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值