[pgsql-jp: 40717] Re: 1:Nの結合に対して更に結合を行う場合の検索性能

[Itagaki Takahiro]

2011/3/21 武田 憲太郎 <takeda ＠ youmind.jp>:
> ところが、予想外と言うか予想通りというか、t1,t2の件数が増えると
> あるタイミングで突然SeqScanに変わります。（突然ガクンと性能落ちます）
> Nの値にアプリケーション側で制限をかけていても、変わるときは変わります。

まずは EXPLAIN ANALYZE の結果を見てみたいですね。
オプティマイザの見積りに誤りがあるのか、
見積りは妥当でもコスト計算に判断ミスがあるのかの違いは重要です。

まずお手軽なのは、そのクエリの直前に：
・SET LOCAL enable_seqscan = off
を挟むことです。
その他に、ちゃんとコストパラメータをチューニングするなら：
・random_page_cost を 1.x～2 程度まで引き下げる。
・cpu_xxx_cost を 10倍程度に引き上げる。
あたりは、よく使われるのではないでしょうか。
（特にキャッシュヒット率が高い環境で。）

> 対策として、
> ・effective_cache_sizeを増加させる
> 一旦はこれで解決します。ところが、更に件数が増えると
> やはり再度SeqScanとなってしまうため、イタチごっこな気がします。

個人的には、effective_cache_size が結果に影響しづらいのは
現在のオプティマイザの問題だと思っています。I/O コストって
本来はキャッシュヒット率ぶんだけは軽減されるべきなので、
もっとアグレッシブに反映されても良いような気はするんですが……。

-- 
Itagaki Takahiro