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解决了;事实上，docs for 8.0有警告但docs for 8.1没有。

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

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

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

看起来kuupaev是kuupäev，或者是日期，而kellaaeg可能是时间。如果是这样的话：永远不要使用连接（||）运算符来组合日期和时间;使用间隔加法，例如kuupaev + kellaaeg。我应该使用数据类型char或time interval来CHECK取决于kellaaeg，而不是timestamp，具体取决于它的含义以及是否仅限于timestamp with time zone 24小时与否。或者，更好的是，使用类型kellaaeg（本地时间）或kuupaev（全球时间）的单个字段来存储组合的日期和时间。

如果您这样做，您可以在合并列上创建一个简单索引，替换min和max，并将其用于date_trunc和extract等内容。如果您只需要日期部分或某些内容的时间部分，请使用date_part，date和time函数;见文档。

有关standard_conforming_strings和bytea_output列不同的另一个示例，请参阅this earlier answer。

您仍应计划升级至9.2。从8.4到9.2的升级路径不是太粗糙，您实际上只需要注意默认情况下escape的设置以及hex从{{1}}到{{}的更改1}}。在转换和移植工作期间，两者都可以设置回8.4默认值。 8.4将不再支持更长时间。

Answer 2

我的第一直觉是尝试索引：

 create index algsa_laonr_kuupaev_kellaaeg_idx
 on ALGSA (laonr asc, (kuupaev||kellaaeg) desc)

...并尝试查询：

 SELECT kuupaev||kellaaeg as res
 from ALGSA 
 where laonr=1 and
       kuupaev||kellaaeg <= '9999-12-3123 59'
 order by
       laonr asc,
       kuupaev||kellaaeg desc
 limit 1

如何加快max（）查询速度

2 个答案: