postgresql 9.2上的慢计数(*)

发布时间：2020-12-13 16:08:43 所属栏目：百科来源：网络整理

导读：关于缓慢计数(*)之前版本9.2,这里和那里(包括关于postgres web的官方帖子)有一些讨论;不知怎的,我没有找到满意的答案. 基本上我安装了postgres 9.1,我观察到慢计数(*)就像 select count(*) from restaurants; 在记录为100k的表上.平均要求约为850毫秒.好吧,

关于缓慢计数(*)之前版本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上配置任何内容才能启用该功能？

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

解决方法

查看索引仅扫描wiki条目：

> What types of queries may be satisfied by an index-only scan?
> is count(*) much faster now?
> Why isn’t my query using an index-only scan?

特别是,我引述：

It is important to realise that the planner is concerned with
minimising the total cost of the query. With databases,the cost of
I/O typically dominates. For that reason,“count(*) without any
predicate” queries will only use an index-only scan if the index is
significantly smaller than its table. This typically only happens when
the table’s row width is much wider than some indexes’.

另请参阅VACUUM和ANALYZE的讨论,以维护可见性图.基本上,您可能希望使VACUUM更具侵略性,并且您希望在首次加载后手动对表进行VACUUM ANALYZE.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!