2015-10-08 17 views
6

neden basit sorgu yürütme yokYalnızca Dizin Taraması neden bu kadar uzun sürüyor?

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

(10 dakikadan fazla bu kez) kadar uzun sürdü? İşte

sorgu planı (çıkış ANALİZİ AÇIKLAYINIZ):

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 

ve PostgreSQL sürümünü:

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

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

endeksi Kimliği sahada, da burada

cevap

3

Yalnızca Dizin Taraması PostgreSQL'de tarama işlemi, bazen sayfalar bilgi içermediği için bazen tabloya (yığın) bakmak zorundadır. tuple görünürlük hakkında. Yani kaç satır dizinden getirilen ne kadar var:

(gerçek ... satırlar = 19517989

Ve bu kaç satır yığın yeniden kontrol edildi edebilirsiniz:

Öbek getirir: 10351403

bunu hızlandırmak için, size masaya vakum çalışmalıdır: vacuum Activity

Vakum, visibility map'u güncelleyecektir ve bu Endeks Yalnızca Tara, yalnızca (hemen) yalnızca dizin sayfalarını kullanarak performans gösterecektir.

+0

Etkinlik tablosunda VACUUM'u (VERBOSE, ANALYZE) yaptım. Bundan sonra, aynı SELECT komutunun çıktısı şuna benzer: http://pastebin.com/KJqHTAGA Şimdi bile yeniden kontrol edilen satırların miktarı çok büyük. Ama aslında üç kat daha hızlı çalışır. – y434y

+0

Gelecekteki iyileştirmelerin mevcut olduğunu düşünüyor musunuz? – y434y

+0

Tam sayıma ihtiyacınız varsa bir tane göremiyorum. Ancak, sizin için yeterli bir tahmin varsa, bunu okuyun: https://wiki.postgresql.org/wiki/Slow_Counting –

İlgili konular