1

ほぼ 100 万行のかなり大きなテーブルがあり、一部のクエリには長い時間がかかります (1 分以上)。

ここで私に特に苦労させているものがあります...

EXPLAIN ANALYZE SELECT "apps".* FROM "apps" WHERE "apps"."kind" = 'software' ORDER BY itunes_release_date DESC, rating_count DESC LIMIT 12;
                                                           QUERY PLAN                                                            
---------------------------------------------------------------------------------------------------------------------------------
 Limit  (cost=153823.03..153823.03 rows=12 width=2091) (actual time=162681.166..162681.194 rows=12 loops=1)
   ->  Sort  (cost=153823.03..154234.66 rows=823260 width=2091) (actual time=162681.159..162681.169 rows=12 loops=1)
         Sort Key: itunes_release_date, rating_count
         Sort Method: top-N heapsort  Memory: 48kB
         ->  Seq Scan on apps  (cost=0.00..150048.41 rows=823260 width=2091) (actual time=0.718..161561.149 rows=808554 loops=1)
               Filter: (kind = 'software'::text)
 Total runtime: 162682.143 ms
(7 rows)

では、それを最適化するにはどうすればよいでしょうか。PG バージョンは 9.2.4、FWIW です。

とには既にインデックスがkindありkind, itunes_release_dateます。

4

3 に答える 3

3

たとえば のインデックスが見つからないようです(kind, itunes_release_date desc, rating_count desc)。

于 2013-06-03T14:13:01.740 に答える
0

appsテーブルの大きさは？postgres に少なくともこれだけのメモリが割り当てられていますか? 毎回ディスクから読み取る必要がある場合、クエリの速度ははるかに遅くなります。

役立つ可能性があるもう 1 つの方法は、「apps」列でテーブルをクラスター化することです。softwareこれにより、すべての行がディスクに順次格納されるため、ディスク アクセスが高速化される場合があります。

于 2013-06-03T14:20:27.363 に答える
0

このクエリを高速化する唯一の方法は、 に複合インデックスを作成すること(itunes_release_date, rating_count)です。Postgres がインデックスから最初の N 行を直接選択できるようになります。

于 2013-06-03T14:20:43.780 に答える