Postgres:按日期时间优化查询

Hen*_*hiu 5 sql postgresql performance postgresql-performance

我有一个日期时间字段为"updated_at"的表.我的很多查询都会使用范围查询来查询此字段,例如update_at>某个日期的行.

我已经为updated_at添加了一个索引,但是我的大多数查询仍然非常慢,即使我对返回的行数有限制.

我还可以做些什么来优化查询日期时间字段的查询?

Boh*_*ian 7

通常数据库优化器不会选择对开放范围使用索引,例如updated_at > somedate.

但是,在许多情况下,数据时间列不会超过“现在”,因此您可以通过使用如下> somedate方式将条件转换为范围来保留 的语义between

where updated_at between somedate and current_timestamp
Run Code Online (Sandbox Code Playgroud)

一个between谓语是更可能导致优化器选择使用索引。


如果此方法提高了查询的性能,请发布。

  • 如果有用,Postgres **将**使用`>` 的索引。不需要“之间”:参见此处的示例 http://sqlfiddle.com/#!12/e3142/3 这一切都取决于 - 像往常一样使用索引 - 使用索引的成本是否更低比别的东西 (6认同)
  • 这真的适用于 PostgreSQL 吗?我认为优化器会通过 pg_statistics 查看相关列中的值范围,并为谓词生成结果集的估计基数。如果最大值小于或等于 current_timestamp 那么我认为不会有太大差异。不过让亨利测试很有趣——解释计划会揭示一切。 (3认同)

dmg*_*dmg 5

对于任何给定查询,索引的使用取决于与顺序扫描相比使用该索引的成本

开发人员经常认为,因为有索引,所以查询应该运行得更快,而如果查询运行得很慢,索引就是解决方案。当查询将返回几个元组时,通常是这种情况。但是,随着结果中元组数量的增加,使用索引的成本可能会增加。

您正在使用postgres。Postgres不支持围绕给定属性进行聚类。这意味着postgres在遇到范围查询(类型为att> a和att <b)时需要计算结果中元组数量的估计(确保您频繁清理数据库)以及使用成本与进行顺序扫描相比的索引。然后,它将决定使用哪种方法。

您可以通过运行检查此决定

EXPLAIN ANALYZE <query>; 
Run Code Online (Sandbox Code Playgroud)

在psql中。它会告诉您是否使用索引。

如果您确实要使用索引而不是顺序扫描(有时是必需的),并且您真的知道自己在做什么,则可以更改计划程序常量中的顺序扫描成本,或者禁用顺序扫描任何其他方法。详细信息请参见此页面:

http://www.postgresql.org/docs/9.1/static/runtime-config-query.html

确保您浏览文档的正确版本。

--dmg