PostgreSQL中的索引查询性能不稳定

时间:2013-01-31 20:30:13

标签: sql performance postgresql indexing

需要有关PostgreSQL中查询性能的帮助。它似乎与索引有关。

此查询:

  • 根据type
  • 过滤
  • timestamp排序,升序:

SELECT * FROM the_table WHERE type = 'some_type' ORDER BY timestamp LIMIT 20

指数:

 CREATE INDEX the_table_timestamp_index ON the_table(timestamp);

 CREATE INDEX the_table_type_index ON the_table(type);

type字段的值只是大约11种不同字符串中的一种 问题是查询似乎在O(log n)时间内执行,大多数时间只执行几毫秒,除了type的某些值,这些值需要几分钟才能运行。

在这些示例查询中,第一个只运行几毫秒而第二个需要超过30分钟:

SELECT * FROM the_table WHERE type = 'goq' ORDER BY timestamp LIMIT 20
SELECT * FROM the_table WHERE type = 'csp' ORDER BY timestamp LIMIT 20

我怀疑,大约90%的确定性,我们拥有的索引不是正确的。我认为,在阅读this similar question about index performance之后,我们最需要的是一个综合索引,超过typetimestamp

我运行的查询计划在这里:

  1. Expected performance, type-specific index (i.e. new index with the type = 'csq' in the WHERE clause)。
  2. Slowest, problematic case, indexes as described above.
  3. Fast case, same indexes as above.
  4. 非常感谢你的帮助!任何指针都会非常感激!

2 个答案:

答案 0 :(得分:2)

索引可用于where子句或order by子句。使用索引thetable(type, timestamp),可以为两者使用相同的索引。

我的猜测是,Postgres根据收集的统计数据决定使用哪个索引。当它使用where的索引然后尝试排序时,你会得到非常糟糕的性能。

这只是一个猜测,但值得创建上述索引以确定是否能解决性能问题。

答案 1 :(得分:2)

explain输出都使用timestamp索引。这可能是因为类型列的基数太低,因此对该列上的索引进行扫描与表扫描一样昂贵。

要创建的复合索引应为:

create index comp_index on the_table ("timestamp", type)

按此顺序。