如何加快max()查询速度

Question

在PostgreSql 8.4中查询

explain analyze SELECT 
    max( kuupaev||kellaaeg ) as res
  from ALGSA 
  where laonr=1 and kuupaev <='9999-12-31' and 
     kuupaev||kellaaeg <= '9999-12-3123 59'

需要3秒才能运行:

"Aggregate  (cost=3164.49..3164.50 rows=1 width=10) (actual time=2714.269..2714.270 rows=1 loops=1)"
"  ->  Seq Scan on algsa  (cost=0.00..3110.04 rows=21778 width=10) (actual time=0.105..1418.743 rows=70708 loops=1)"
"        Filter: ((kuupaev <= '9999-12-31'::date) AND (laonr = 1::numeric) AND ((kuupaev || (kellaaeg)::text) <= '9999-12-3123 59'::text))"
"Total runtime: 2714.363 ms"

如何在PostgreSQL 8.4.4中加快速度？表结构如下.algsa表有关于kuupaev的索引也许这可以用吗？或者是否可以更改查询以添加其他索引以使其快速.表格中的列数不能更改.

CREATE TABLE firma1.algsa
(
  id serial NOT NULL,
  laonr numeric(2,0),
  kuupaev date NOT NULL,
  kellaaeg character(5) NOT NULL DEFAULT ''::bpchar,
  ... other columns
  CONSTRAINT algsa_pkey PRIMARY KEY (id),
  CONSTRAINT algsa_id_check CHECK (id > 0)
)
);

CREATE INDEX algsa_kuupaev_idx  ON firma1.algsa  USING btree  (kuupaev);

更新

试着 analyze verbose firma1.algsa;

INFO:  analyzing "firma1.algsa"
INFO:  "algsa": scanned 1640 of 1640 pages, containing 70708 live rows and 13 dead rows; 30000 rows in sample, 70708 estimated total rows
Query returned successfully with no result in 1185 ms.

但查询运行时间仍为2.7秒.

为什么会这样30000 rows in sample .是不是太多了,这应该减少吗？

Answer 1

这是旧版PostgreSQL中的一个已知问题 - 但看起来它可能已经被8.4解决了; 事实上,8.0的文档有警告但8.1的文档没有.

因此,您至少不需要升级主要版本.但是,您应该升级到当前的8.4系列版本8.4.16,因为您错过了几年的错误修复和调整.

这里真正的问题是你使用max的是表达式而不是简单的值,并且该表达式没有功能索引.

您可以尝试在表达式上创建索引kuupaev||kellaaeg...但我怀疑您有数据模型问题,并且通过修复数据模型可以获得更好的解决方案.

它看起来像kuupaevkuupäev,或者日期,而kellaaeg可能是时间.如果是这样的话:永远不要使用concatenation(||)运算符来组合日期和时间; 使用间隔加法,例如kuupaev + kellaaeg.而不是char你应该使用数据类型time或interval具有CHECK约束kellaaeg,取决于它的含义以及它是否限制在24小时内.或者,更好的是,使用单个字段类型timestamp(用于本地时间)或timestamp with time zone(用于全局时间)来存储组合的日期和时间.

如果你这样做,你可以创建合并列取代了一个简单的指标kellaaeg,并kuupaev和使用,对于min和max等等.如果你只需要日期部分或只是一些事情的时间部分,使用date_trunc,extract和date_part功能; 看文档.

请参阅前面的答案,了解另外一个例子,其中单独date和time列是一个坏主意.

您仍应计划升级到9.2.从8.4到9.2的升级路径不可过于粗糙,你真的只需要注意的设置standard_conforming_strings在默认情况下和变化bytea_output的escape到hex.在转换和移植工作期间,两者都可以设置回8.4默认值.8.4将不再支持更长时间.