クエリ:
SELECT "replays_game".*
FROM "replays_game"
INNER JOIN
"replays_playeringame" ON "replays_game"."id" = "replays_playeringame"."game_id"
WHERE "replays_playeringame"."player_id" = 50027
を設定SET enable_seqscan = offすると、次のような高速処理が実行されます。
QUERY PLAN
--------------------------------------------------------------------------------------------------------------------------------------------------------------------
Nested Loop (cost=0.00..27349.80 rows=3395 width=72) (actual time=28.726..65.056 rows=3398 loops=1)
-> Index Scan using replays_playeringame_player_id on replays_playeringame (cost=0.00..8934.43 rows=3395 width=4) (actual time=0.019..2.412 rows=3398 loops=1)
Index Cond: (player_id = 50027)
-> Index Scan using replays_game_pkey on replays_game (cost=0.00..5.41 rows=1 width=72) (actual time=0.017..0.017 rows=1 loops=3398)
Index Cond: (id = replays_playeringame.game_id)
Total runtime: 65.437 ms
しかし、恐ろしい enable_seqscan がなければ、より遅いことを選択します。
QUERY PLAN
--------------------------------------------------------------------------------------------------------------------------------------------------------------------
Hash Join (cost=7330.18..18145.24 rows=3395 width=72) (actual time=92.380..535.422 rows=3398 loops=1)
Hash Cond: (replays_playeringame.game_id = replays_game.id)
-> Index Scan using replays_playeringame_player_id on replays_playeringame (cost=0.00..8934.43 rows=3395 width=4) (actual time=0.020..2.899 rows=3398 loops=1)
Index Cond: (player_id = 50027)
-> Hash (cost=3668.08..3668.08 rows=151208 width=72) (actual time=90.842..90.842 rows=151208 loops=1)
Buckets: 1024 Batches: 32 (originally 16) Memory Usage: 1025kB
-> Seq Scan on replays_game (cost=0.00..3668.08 rows=151208 width=72) (actual time=0.020..29.061 rows=151208 loops=1)
Total runtime: 535.821 ms
関連するインデックスは次のとおりです。
Index "public.replays_game_pkey"
Column | Type | Definition
--------+---------+------------
id | integer | id
primary key, btree, for table "public.replays_game"
Index "public.replays_playeringame_player_id"
Column | Type | Definition
-----------+---------+------------
player_id | integer | player_id
btree, for table "public.replays_playeringame"
だから私の質問は、Postgres が参加する 2 つの方法の相対的なコストを誤って見積もっているということです。コストの見積もりで、ハッシュ結合が高速になると考えていることがわかります。そして、インデックス結合のコストの見積もりは、500 倍ずれています。
Postgresにもっと手がかりを与えるにはどうすればよいですか? 上記のすべてを実行するVACUUM ANALYZE直前に実行しました。
興味深いことに、ゲーム数が少ないプレイヤーに対してこのクエリを実行すると、Postgres はインデックス スキャン + ネスト ループを実行することを選択します。したがって、多数のゲームについての何かが、相対的な推定コストが実際の推定コストと一致しないこの望ましくない動作をくすぐります。
最後に、Postgres を使用する必要がありますか? 私はデータベース チューニングの専門家になりたいわけではないので、専任の DBA とは対照的に、良心的な開発者レベルの注意を払って適切に機能するデータベースを探しています。私が Postgres を使い続けると、このような問題が絶え間なく発生し、Postgres の専門家にならざるを得なくなるのではないかと心配しています。
Postgres の専門家 (RhodiumToad) が私の完全なデータベース設定 ( http://pastebin.com/77QuiQSp ) をレビューし、 set cpu_tuple_cost = 0.1. それは劇的なスピードアップをもたらしました: http://pastebin.com/nTHvSHVd
または、MySQL に切り替えることで、問題もかなりうまく解決しました。私の OS X ボックスには MySQL と Postgres のデフォルト インストールがあり、MySQL は 2 倍高速であり、クエリを繰り返し実行することによって「ウォームアップ」されたクエリを比較しています。「コールド」クエリ、つまり特定のクエリが初めて実行されるとき、MySQL は 5 ～ 150 倍高速です。コールド クエリのパフォーマンスは、特定のアプリケーションにとって非常に重要です。
私に関する限り、大きな問題はまだ未解決です。Postgres を適切に実行するには、MySQL よりも多くの調整と構成が必要ですか? たとえば、ここでコメンターが提供した提案がどれも機能しなかったと考えてください。