postgresql上的缓存数（*）9.2

这里和那里有几个讨论（包括postgres网站上的官方文章）关于缓慢计数（*）之前版本9.2;不知何故，我没有找到满意的答案。postgresql上的缓存数（*）9.2

基本上我不得不安装postgres的9.1，并且我观察慢计数（*）作为

select count(*) from restaurants;

简单对带有100K +记录的表。平均要求大约是850ms。好吧，我认为这是人们一直在讨论postgres 9.1及以下版本缓慢的症状，因为postgres 9.2有一些新功能，如仅索引扫描。我想通过使用9.1中相同的数据集并将其放在9.2上来进行实验。我打电话给伯爵声明，它仍然给出了一个不好的结果，如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上配置什么来启用该功能？

P.S. 其中条款也不帮助我的情况。

来源

2012-12-13 Ream

您是否阅读过https://wiki.postgresql.org/wiki/Index-only_scans？这里有一个关于“count”和它的限制的讨论。该表上是否有主键？加载数据后，您是否在表中加入了“VACUUM”和“ANALYZE”？ –

另外，你的'random_page_cost'和'seq_page_cost'设置为？ 'effective_cache_size'怎么样？ –

谢谢Craig的链接。我按照你的建议读了它并做了VACUUM，不知何故它将速度从850ms提高到了400ms。仍然是400ms是一个昂贵的时间。是否有任何额外的调整方法来完善？ – Ream

看到索引只扫描维基条目：

特别是，我引述：

这是REA重要明确规划人员与有关最小化查询的总成本。使用数据库， I/O的成本通常占主导地位。因此，如果索引为的查询将显着小于其表格，则“count（*）without predicate”查询将仅使用仅索引扫描。这通常只发生在表的行宽比某些索引宽得多时。

另见VACUUM和ANALYZE讨论维持知名度地图。实质上，您可能想要使VACUUM更具侵略性，并且您需要在第一次加载该表后手动输入VACUUM ANALYZE。

来源

2012-12-13 07:58:17

postgresql上的缓存数（*）9.2

回答

相关问题