postgresql 9.2上的慢计数(*)

Question

关于缓慢计数(*)之前版本9.2,这里和那里(包括关于postgres web的官方帖子)有一些讨论; 不知怎的,我没有找到满意的答案.

基本上我安装了postgres 9.1,我观察到慢计数(*)就像

select count(*) from restaurants;

在记录为100k +的表上.平均要求约为850毫秒.好吧,我认为这是人们一直在讨论的postgres 9.1及以下的缓慢计数的症状,因为postgres 9.2有一些新功能,如仅索引扫描.我想通过使用9.1中的相同数据集进行实验,并将其放在9.2上.我调用count语句,它仍然会给出一个不好的结果,如9.1.

explain analyze select count(*) from restaurants;
------------------------------------------------------------------
Aggregate  (cost=23510.35..23510.36 rows=1 width=0) (actual time=979.960..979.961 rows=1 loops=1)
   ->  Seq Scan on restaurants  (cost=0.00..23214.88 rows=118188 width=0) (actual time=0.050..845.097 rows=118188 loops=1)
 Total runtime: 980.037 ms

谁能建议这个问题的可行解决方案？我是否需要在postgres上配置任何内容才能启用该功能？

PS where子句对我的情况也没有帮助.

Answer 1

查看索引仅扫描 wiki 条目：

• 仅索引扫描可以满足哪些类型的查询？
• count(*)现在快多了？
• 为什么我的查询不使用仅索引扫描？

我特别引用：

重要的是要认识到规划器关心的是最小化查询的总成本。对于数据库，I/O 成本通常占主导地位。因此，如果索引明显小于其表，“不带任何谓词的 count(*)”查询将仅使用仅索引扫描。这种情况通常仅在表的行宽比某些索引宽得多时才会发生。

VACUUM另请参阅有关ANALYZE维护可见性地图的讨论。本质上，您可能想要VACUUM更加激进，并且您需要VACUUM ANALYZE在首次加载表后手动操作该表。