6

バージョン 9.2 より前の遅いカウント (*) について、あちこちで (postgres Web の公式投稿を含めて) いくつかの議論があります。どういうわけか私は満足のいく答えを見つけられませんでした。

基本的に私はpostgres 9.1をインストールしていましたが、スローカウント（*）は次のように単純でした

select count(*) from restaurants;

100k+ のレコードを持つテーブル。平均リクエストは約850msです。postgres 9.2 にはindex-only scan のような新しい機能があるため、postgres 9.1 以下でカウントが遅いことについて人々が話していた症状だと思いました。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句は私の場合も役に立ちません。

4

2 に答える 2

2

インデックスはwikiエントリのみをスキャンします。

特に、私は引用します：

計画担当者は、クエリの総コストを最小限に抑えることに関心があることを理解することが重要です。データベースでは、通常、I/Oのコストが支配的です。そのため、「述語なしのcount（*）」クエリは、インデックスがテーブルよりも大幅に小さい場合にのみ、インデックスのみのスキャンを使用します。これは通常、テーブルの行幅が一部のインデックスよりもはるかに広い場合にのみ発生します。

可視性マップの維持VACUUMについての説明も参照してください。ANALYZE基本的に、おそらくもっと積極的にしたいと思うでしょうし、最初にテーブルをロードした後VACUUMに手動でテーブルを作りたいと思うでしょう。VACUUM ANALYZE

于 2012-12-13T07:58:17.603 に答える