使用索引

仅使用索引中的信息就无法回答PostgreSQL中的查询。从正在执行的查询的角度来看，该行是否可见，存储在主行本身中。因此，当您向某物添加索引并执行使用该索引的查询时，涉及两个步骤： 浏览索引以确定使用了哪些数据块 检索这些块并返回与查询匹配的行 因此，用索引回答查询可能比直接进入数据块并获取行要花费更长的时间。发生这种情况的最常见情况是，您实际上是在获取大部分数据。通常，如果使用了表的20％以上，则按顺序访问它被认为是快速的。有时，计划者认为将访问不到20％的内容，因此首选索引，但这不是事实。这是添加索引可以减慢查询速度的一种方法。根据您的描述，这可能就是您遇到的情况-如果大范围接触的表超出了优化程序的估计，则使用索引可能会导致网络速度减慢。 为了弄清楚这一点，数据库收集了有关每个表中每个列的统计信息，以确定特定的WHERE条件是否具有足够的选择性以使用索引。这个想法是，您需要通过不阅读整个表来保存这么多的块，以至于在它上面添加索引I / O仍然是赢家。 这种计算可能会出错，在某些情况下，与直接读取表相比，您完成的I / O操作更多。如果使用EXPLAIN ANALYZE运行查询，则会显示其中大多数的原因。如果\“ expected \”值与\“ act \\”值相差很大，则可能表明优化器的表统计信息不正确。另一种可能性是，优化器只是在查询的选择性上犯了一个错误-它认为它只会返回少量的行，但实际上会返回大部分表。同样，在这里，更好的统计数据是开始进行此工作的正常方法。如果您使用的是PostgreSQL 8.3或更早版本，则默认情况下收集的统计信息数量很少。 某些工作负载最终还调整了random_page_cost可调参数，从而控制了索引与表扫描权衡的发生位置。不过，这只是统计信息被检查后要考虑的事情。有关可以在此处调整的几项内容的介绍，请参见调整PostgreSQL服务器。     

我会尝试几件事： 增加数据库缓存参数 在该日期字段上添加索引 重新设计/修改应用程序以使其在较小的范围内工作（尽管这个建议似乎很明显，通常通常会先将其丢弃）     

  为此日期字段创建索引可以提高读取较小日期范围的查询的性能，但是在较大日期范围内，性能会下降... 尝试使用该索引对表进行集群。性能下降可能是由于整个表在较大范围内打开所致。如果是这样，将表沿着该索引聚簇将导致更少的磁盘搜寻。     

两个建议： 1）研究将“ 0”用于时序数据。例如，每月创建一个子表，然后在每个表上索引日期。 PostgreSQL非常聪明，只对在日期范围内具有实际数据的子表执行“ 1”。子表由于是新月而被“密封”后，在表上运行

CLUSTER

以按日期对数据进行排序。 2）看一下使用

WHERE

子句创建一堆

INDEX

\。 建议1将长期成为赢家，但会花一些时间进行设置（但会永久缩放/运行），但是建议2如果您对扫描的日期范围有限，可能是一种快速的临时解决方案。请记住，您只能在

INDEX

\的

WHERE

子句中使用

IMMUTABLE

函数。

CREATE INDEX tbl_date_2011_05_idx ON tbl(date) WHERE date >= \'2011-05-01\' AND date <= \'2011-06-01\';