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

[武田 憲太郎]

板垣様

早速ありがとうございます。

今回のケースに限っては、

>まずお手軽なのは、そのクエリの直前に：
>・SET LOCAL enable_seqscan = off
>を挟むことです。

これで解決できそうな気がします。一旦設定変更して様子を見ます。
この設定、マニュアルから見落としてました。

・結合は「t1->t2->t3」の二段階。
・t1:t2=1:N(Nは不定)、t2:t3=1:1。
　↓
・t1:t3=1:N(Nは不定)
　↓
・Nは（インデックス使って欲しい程度に）少ないと分かってる。
・オプティマイザがそう見積もらなくなった時点で一気に負荷が上がる。
　↓
・Nの値に制限をかけていることはプログラム的に解っている。
・強制的にインデックス使わせてOK？

>まずは EXPLAIN ANALYZE の結果を見てみたいですね。

現象が発生したサービスは既に「サブクエリ」の案で対策済みのため
EXPLAIN ANALYZEの結果はすぐにはお出しできそうにありませんが、
記憶している限りEXPLAINの見積もりでで既に膨大なコストでした。
（次に発生した際はenable_seqscanの設定を変更した値も取ってみます）

ありがとうございました。大変助かりました。


-----Original Message-----
From: Itagaki Takahiro [mailto:itagaki.takahiro ＠ gmail.com] 
Sent: Monday, March 21, 2011 10:52 PM
To: PostgreSQL Japanese Mailing List
Cc: 武田 憲太郎
Subject: Re: [pgsql-jp: 40715] 1:Nの結合に対して更に結合を行う場合の検索性能

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