2015-10-08 11 views
6

はなぜ私の単純なクエリを実行んなぜインデックススキャンのみが長時間かかるのですか?

select count(this_.Id) as y0_ from Activity this_ 

は(10分以上、この時間)時間がかかるの?ここで

クエリプランは、(ANALYZE EXPLAINの出力)である:

QUERY PLAN 
Aggregate (cost=854047.36..854047.37 rows=1 width=4) 
> (actual time=728525.277..728525.277 rows=1 loops=1) 
-> Index Only 
> Scan using activity_pkey on activity this_ (cost=0.56..805401.87 
> rows=19458196 width=4) (actual time=36.961..725381.557 rows=19517989 
> loops=1) 
> Heap Fetches: 10351403 
Total runtime: 728533.529 ms 

とPostgreSQLのバージョン:

PostgreSQL 9.3.5 on x86_64-unknown-linux-gnu, compiled by gcc (Debian 4.7.2-5) 4.7.2, 64-bit 

インデックスはIdフィールドに、あまりにもここにある:

ALTER TABLE public.activity 
ADD CONSTRAINT activity_pkey 
PRIMARY KEY (id); 

答えて

3

インデックスページには情報が含まれていないため、PostgreSQLでのスキャンのみがテーブル(ヒープ)に表示されることがあります。タプルの可視性について

(実際の...行= 19517989

そして、それがヒープに再チェックした行数です:

多くの行がインデックスからフェッチされた方法です ヒープフェッチ:10351403

高速化するには、テーブルを空にする必要があります。vacuum Activity

Vacuumはvisibility mapを更新し、そのインデックススキャンは(ほぼ)インデックスページのみを使用して実行できます。

+0

アクティビティテーブルでVACUUM(VERBOSE、ANALYZE)を実行しました。この後、同じSELECTコマンドの出力は次のようになります。http://pastebin.com/KJqHTAGA現在でも、再チェックされた行の量は膨大です。しかし、実際には3倍の速さで実行されます。 – y434y

+0

今後の改善がありますか? – y434y

+0

正確な数が必要な場合、私は1つを見ることができません。しかし、見積もりが十分であれば、これを読んでください:https://wiki.postgresql.org/wiki/Slow_Counting –

関連する問題