Joinの特性上いい感じの実行計画にさせるにはどうHintingするのが良いのか考えてみたいと思います。(答えが見えている方は多いとは思いますけどもw)以下のSQL文を使い、後述のような実行計画に制御することを目指してみます。;いざというときに慌てずに、どうするかを判断、チューニングできるようになっておくと良いですよねー。言う、いざ、という場面には付き合わされない人も、雑学的になんとなーーーく理解しているだけでも良いのではないかと思います。Oracleの実行計画風ですが、こんな実行計画にオプティマイザーヒントだけで制御してみたいなぁ。右側にコメントしているBuild/Probeの関係を覚えておいてください。この形にするのが目的です。(予習に目を通した方は、あ”〜っ。と何かに気づいちゃったと思いますけどもw)ポイントになるのは、t0の結合です。t1,t2,t3,t4と結合した結果が、t0の行数より多くなります。Joinを想定しているので、最後にt0を結合する場合には、t0をBuildにしたいですよね。できるけど、Build/Probeの制御ができない。Treeにしかならないのもどうしようもない。Joinの結合ツリーにも癖がでるまず、Oracleからですかねぇ。豊富なオプティマイザヒントと最適化が行えることが強みの一つだと思います。NO_SWAP_JOIN_INPUTSを使ってますが、実行計画としては狙ったところに持っていけますよね。Oraclerの方なら、ふむふむ。いうところだと思います。実践でも結構使う場面はありますよね。Treeになるように、SWAP_JOIN_INPUTSしてます。Join狙った実行計画に制御できました。参考)使ったSQLスクリプトは以下の通り。shared_preload_libraries-----------------------------------------------pg_hint_planpg_hint_planのLeadingヒントの使い方慣れるまで結構迷子になってましたw。空気感でなんとなーく使い方を理解できたかなぁ。pg_hint_planのLeading(pair)の書き方と、順序の指定順って、Oraclerの感覚的には逆なんですよね。