Question

我的某个表格上有一个索引，例如

CREATE INDEX myindex
  ON mytable
  USING btree
  (myfield1, myfield2, myfield3 DESC NULLS LAST, myfield4 DESC, myfield5)
  WHERE myfield6 IS NOT NULL;

我正在尝试优化请求

SELECT COUNT(*) 
FROM "mytable" 
WHERE (myfield1 = 9 
   AND myfield5<164 
  AND myfield2 <= 40.0 
  AND (myfield6 IS NOT NULL))

=> count: 7116

Aggregate  (cost=10780.84..10780.85 rows=1 width=0)
  ->  Index Scan using myindex on mytable  (cost=0.42..10751.64 rows=11683 width=0) 
        Index Cond: ((myfield1 = 9) AND (myfield2 <= 40::double precision) AND (myfield5 < 164))

通过测试，我发现更换＆＃34; myfield2＆lt; = 40.0＆＃34; by＆＃34; myfield2不为空且myfield2＆lt; = 40.0＆＃34;给出相同的结果，使用相同的索引，但成本是前一个请求的一半

SELECT COUNT(*) 
FROM "mytable" 
WHERE (myfield1 = 9 
   AND myfield5<164 
   AND myfield2 is not null 
   AND myfield2 <= 40.0 
   AND (myfield6 IS NOT NULL))
=> count: 7116

Aggregate  (cost=4467.24..4467.25 rows=1 width=0)
  ->  Index Scan using myindex on mytable  (cost=0.42..4455.91 rows=4533 width=0)
        Index Cond: ((myfield1 = 9) AND (myfield2 IS NOT NULL) AND (myfield2 <= 40::double precision) AND (myfield5 < 164))

我无法理解为什么成本要低得多？

Answer 1

PostgreSQL的人工智能也不够高，无法知道满足

的所有行

myfield1 = 9 AND myfield5 < 164 AND myfield2 <= 40.0 AND myfield6 IS NOT NULL

必须满足

myfield2 IS NOT NULL

这里总是存在一种权衡 - 更聪明的计划者意味着更长的计划时间，并且惩罚每个人以获得只能通过“糟糕”查询获得的利益是一个坏的赌注。

这些条件将被视为独立的。

根据您的数字，我猜测超过一半的行myfield2 IS NULL。

postgres优化非空

1 个答案: