第3回 PostgreSQLを遅くしている犯人はどこだ?

下垣徹
NTT OSSセンタ
2008/6/9

EXPLAIN ANALYZEの実行結果


                       QUERY PLAN
-------------------------------------------------------------------Sort (cost=237934.36..238004.45 rows=28037 width=129) (actual time=9006.586..9011.968 rows=16842 loops=1)
  Sort Key: customer.c_birthdate
  Sort Method: quicksort Memory: 5242kB
  -> Nested Loop (cost=17882.27..235863.12 rows=28037 width=129) (actual time=239.948..8942.154 rows=16842 loops=1)
    -> Hash Join (cost=17882.27..202155.81 rows=56083 width=106) (actual time=239.920..8675.943 rows=33724 loops=1)
      Hash Cond: (orders.o_c_id = customer.c_id)
      -> Seq Scan on orders (cost=0.00..118910.65 rows=5184165 width=49) (actual time=0.011..1521.206 rows=5184000 loops=1)
      -> Hash (cost=17493.29..17493.29 rows=31118 width=65) (actual time=238.938..238.938 rows=37175 loops=1)
        -> Index Scan using customer_pkey on customer (cost=0.00..17493.29 rows=31118 width=65) (actual time=0.059..193.634 rows=37175 loops=1)
          Index Cond: ((c_id >= 1) AND (c_id <= 200000))
          Filter: ((c_birthdate >= '1950-01-01'::date) AND (c_birthdate <= '1969-12-31'::date))
    -> Index Scan using cc_xacts_pkey on cc_xacts (cost=0.00..0.59 rows=1 width=27) (actual time=0.006..0.006 rows=0 loops=33724)         Index Cond: (cc_xacts.cx_o_id = orders.o_id)
Total runtime: 9022.840 ms
(14 rows)
EXPLAIN ANALYZEの実行結果(改行は折りたたんでいます)

 

Index
Linuxトラブルシューティング探偵団
 第3回 PostgreSQLを遅くしている犯人はどこだ?
Page 1
 今回の相手はPostgreSQLの性能
 で、そもそもチューニングって何なのさ?
  Page 2
 性能問題の原因を探る2つのステップ
 どのSQLが遅いのか?
  そのSQLのどこに時間がかかっているのか?
 コラム 実行計画が最適かどうかをチェック
  Page 3
 出力内容を追いかけろ
 こんなに時間がかかる理由は?
 いざ、絞り込んで問題の解決へ
 常に考えをめぐらせながら解決を



Linux & OSS フォーラム 新着記事
@ITメールマガジン 新着情報やスタッフのコラムがメールで届きます(無料)

注目のテーマ

Linux & OSS 記事ランキング

本日 月間