速度差の理由を教えてください。

データベースの構造とインデックス、検索クエリー
全て同じ条件でテストサーバと実際のサーバで
検索を行っているのですが以下のような結果がでます。

なぜ以下の様に10倍まで差が生まれるのかを
教えていただければと思っております。

違う箇所としては、サーバのスペックですが
実際のサーバのCPU：Xeon 3.2GHz メモリ：2GB
テストサーバのCPU：Pentium4 3.2GHz　メモリ：2GB
となります。

//テストサーバでの結果
Limit (cost=99427.05..99427.25 rows=4 width=112) (actual time=4022.29..4022.31 rows=4 loops=1)
-> Unique (cost=99427.05..99438.37 rows=226 width=112) (actual time=4022.29..4022.30 rows=5 loops=1)
-> Sort (cost=99427.05..99432.71 rows=2265 width=112) (actual time=4022.29..4022.29 rows=6 loops=1)
Sort Key: s.saorderid, s.saserialid, o.odlastupdate
-> Merge Join (cost=96997.70..99300.85 rows=2265 width=112) (actual time=3363.93..4022.11 rows=40 loops=1)
Merge Cond: ("outer".odid = "inner".saorderid)
-> Sort (cost=8054.50..8059.58 rows=2033 width=68) (actual time=13.52..13.55 rows=38 loops=1)
Sort Key: o.odid
-> Index Scan using order1_odctmid_index on order1 o (cost=0.00..7942.81 rows=2033 width=68) (actual time=13.13..13.47 rows=38 loops=1)
Index Cond: (odctmid = 3403::bigint)
-> Sort (cost=88943.20..90075.54 rows=452935 width=44) (actual time=3344.05..3688.13 rows=452002 loops=1)
Sort Key: s.saorderid
-> Seq Scan on sale s (cost=0.00..12792.35 rows=452935 width=44) (actual time=0.02..756.03 rows=452935 loops=1)
Total runtime: 4050.02 msec

//実際の本番サーバでの結果
Limit (cost=73933.37..73933.39 rows=1 width=128) (actual time=43102.58..43102.59 rows=4 loops=1)
-> Unique (cost=73933.37..73933.39 rows=1 width=128) (actual time=43102.58..43102.59 rows=5 loops=1)
-> Sort (cost=73933.37..73933.38 rows=5 width=128) (actual time=43102.57..43102.58 rows=6 loops=1)
Sort Key: s.saorderid, s.saserialid, o.odlastupdate
-> Nested Loop (cost=0.00..73933.32 rows=5 width=128) (actual time=998.20..43102.38 rows=40 loops=1)
Join Filter: ("outer".odid = "inner".saorderid)
-> Index Scan using order1_odctmid_index on order1 o (cost=0.00..18.12 rows=4 width=68) (actual time=6.01..6.99 rows=38 loops=1)
Index Cond: (odctmid = 3403::bigint)
-> Seq Scan on sale s (cost=0.00..12797.54 rows=448254 width=60) (actual time=0.01..756.51 rows=455437 loops=38)
Total runtime: 43102.69 msec

もしクエリー文もあった方がよければ
お知らせ下さい。

すみませんが、どなたか教えて頂ければ
と思います。よろしくお願い致します。

No.3 ベストアンサー 回答者： chukenkenkou 回答日時： 2008/02/18 17:49

URLを貼り忘れました。

http://www.postgresql.jp/

また、差が出ているポイントは、テスト環境ではMerge Join、本番環境ではNested Loop さらにloops=38となっている部分だと思います。
具体的に「SQLのどの記述の部分」ということは、インデクスの定義とSQLが分からないと具体的にはアドバイスできません。

この回答へのお礼

遅れましたが
非常にありがたいアドバイスです。
テストと本番ですので、データ量の違いは埋めれない
ないのですが、それでも数千程度の違いでなぜ10倍物
差が出るのか不思議でならなかったのですが、
教えていただいたポイントを頼りにもう少し調べて行きたいと
思います。

どうもありがとう御座います。

お礼日時：2008/02/19 21:28

No.2 回答者： chukenkenkou 回答日時： 2008/02/18 17:36

#1です。

PostgeSQLのバージョンが不明ですが、EXPLAINの表示結果の見方は、マニュアルの次のような箇所にあります。

http://www.postgresql.jp/document/pg800doc/html/ …

私は「専門家」としていますが、PostgreSQLのこの辺の情報の解析、細かな性能に関するパラメタ類に関しては、それ程、詳しくありません。
また、PostgreSQLには、アクセス計画の生成に関するいろいろなパラメタがあるようで、このサイトでは適切に答えられる人はなかなかいません。
日本PostgreSQLユーザ会のメーリングリストに登録し、質問することをお勧めします。（私も登録していて、時々、アドバイスしています）

No.1 回答者： chukenkenkou 回答日時： 2008/02/18 13:59

自分で解析しようと努力しましたか？

ここのサイトは、「分からない部分を具体的示し、質問する」サイトであり、解析
作業を誰かにやってもらうサイトではありません。

>データベースの構造とインデックス、検索クエリー
>全て同じ条件でテストサーバと実際のサーバで
>検索を行っている

データ件数や重複件数などが、全然違うのでは？

ご自身で貼り付けた情報を見てみてください。
操作対象になっている行数が全然違うし、あちこちアクセス計画も違っています。