PG:查詢計劃器與random_page_cost
查詢計劃器與random_page_cost
本周小貼士比較奇怪,基于我們今天遇到的一個問題。將簡訊的鏈接存儲到一個簡單數(shù)據(jù)庫中:
CREATE TABLE links (
uid CHAR(60) PRIMARY KEY,
data TEXT,
timestamp INT
)
CREATE INDEX idx_trgm ON links USING GIN (data gin_trgm_ops)
當(dāng)然,這個設(shè)計比較爛。但僅供內(nèi)部使用,我只是一個粗略的想法原型。數(shù)據(jù)是一個包含json(I know, I know...)的文本,以同樣可怕的方式檢查鏈接的存在:
SELECT * FROM links WHERE data ILIKE '%whatever we want%' LIMIT 1;
在低容量下運行很好,但查詢時間偶爾會超過300ms,很好奇這是為啥?
執(zhí)行EXPLAIN ANALYZE后,發(fā)現(xiàn)PG根本沒使用GIN索引,而是使用了全表掃描。但是如果去掉LMIT 1,查詢將使用索引,執(zhí)行只需要5ms。為什么PG會忽略索引?
PG的查詢規(guī)劃器并不是真正基于人們做一些荒唐的事情。比如使用ILIKE進行全表掃描,關(guān)心的是走索引快還是全表掃描快。變量random_page_cost用于決定使用索引的代價是否值得,或者和seq_page_cost合作使用。
這種情況下,索引掃描是值得的,但是查詢規(guī)劃器不同意。因為看起來很簡單的LIMIT 1,只找到一個結(jié)果就可以停止。并繼續(xù)進行全表掃描。
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]
除了明顯的“修復(fù)那個糟糕的模式”,看看PG會做什么,如果覺得索引掃描和順序掃描比代價低。因此如果最終得到的查詢使用索引,那么有必要嘗試一下,通過EXPLAIN ANALYZE分析。
請輸入評論內(nèi)容...
請輸入評論/評論長度6~500個字
最新活動更多
-
10月31日立即下載>> 【限時免費下載】TE暖通空調(diào)系統(tǒng)高效可靠的組件解決方案
-
即日-11.13立即報名>>> 【在線會議】多物理場仿真助跑新能源汽車
-
11月28日立即報名>>> 2024工程師系列—工業(yè)電子技術(shù)在線會議
-
12月19日立即報名>> 【線下會議】OFweek 2024(第九屆)物聯(lián)網(wǎng)產(chǎn)業(yè)大會
-
即日-12.26火熱報名中>> OFweek2024中國智造CIO在線峰會
-
即日-2025.8.1立即下載>> 《2024智能制造產(chǎn)業(yè)高端化、智能化、綠色化發(fā)展藍皮書》
推薦專題
- 高級軟件工程師 廣東省/深圳市
- 自動化高級工程師 廣東省/深圳市
- 光器件研發(fā)工程師 福建省/福州市
- 銷售總監(jiān)(光器件) 北京市/海淀區(qū)
- 激光器高級銷售經(jīng)理 上海市/虹口區(qū)
- 光器件物理工程師 北京市/海淀區(qū)
- 激光研發(fā)工程師 北京市/昌平區(qū)
- 技術(shù)專家 廣東省/江門市
- 封裝工程師 北京市/海淀區(qū)
- 結(jié)構(gòu)工程師 廣東省/深圳市