回答編集履歴
4
追記
test
CHANGED
|
@@ -13,3 +13,20 @@
|
|
|
13
13
|
> マージ結合： 結合を開始する前に、それぞれのリレーションを結合属性でソートします。 そして、2つのリレーションを並行してスキャンし、一致する行を結合行の形にまとめます。 それぞれのリレーションがたった1回しかスキャンされなくて済むのでこの結合は魅力的です。 要求されるソートは、明示的なソート段階、または、結合キー上のインデックスを使用して適切な順序でリレーションをスキャンすることにより行われます。
|
|
14
14
|
>
|
|
15
15
|
> ハッシュ結合： 右側のリレーションがハッシュキーとして結合属性を用いて初めにスキャンされ、ハッシュテーブルに読み込まれます。 次に左側のリレーションがスキャンされ、見つかったそれぞれの行に相応しい値が、右側のリレーションの行を探し出すためのハッシュキーとして使われます。
|
|
16
|
+
|
|
17
|
+
※コメントに対して追記
|
|
18
|
+
> 抽出文の変更かINDEXしか対策はなさそうだと判断いたしました。
|
|
19
|
+
拡張モジュールでヒント文での制御が可能です。
|
|
20
|
+
|
|
21
|
+
[pg_hint_plan (PostgreSQL 実行計画制御ツール)](https://www.sraoss.co.jp/tech-blog/pgsql/pg_hint_plan/)
|
|
22
|
+
|
|
23
|
+
以下抜粋
|
|
24
|
+
> <利用可能なヒントのカテゴリ>
|
|
25
|
+
|||
|
|
26
|
+
|:--|:--|
|
|
27
|
+
|スキャン方式 |テーブルのスキャン方式を指定できます |
|
|
28
|
+
|結合順序 |複数あるテーブルをどの順で結合するか指定できます |
|
|
29
|
+
|結合方式 |テーブル結合の方式を指定できます |
|
|
30
|
+
|見積件数補正 |テーブル結合結果の件数見積もりを補正する指定ができます |
|
|
31
|
+
|パラレル実行 |パラレル実行を強制あるいは禁止する指定ができます |
|
|
32
|
+
|設定パラメータ |SETコマンドで指定できるパラメータ設定をヒントから与えます |
|
3
推敲
test
CHANGED
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
|
|
3
3
|
リファレンスによれば、それぞれの選択肢で計画し一番コストの低いものを選択するとあります。
|
|
4
4
|
|
|
5
|
-
[51.5. プランナ/オプティマイザ](https://www.postgresql.jp/document/1
|
|
5
|
+
[51.5. プランナ/オプティマイザ](https://www.postgresql.jp/document/11/html/planner-optimizer.html)
|
|
6
6
|
|
|
7
7
|
以下抜粋
|
|
8
8
|
|
2
推敲
test
CHANGED
|
@@ -1,10 +1,13 @@
|
|
|
1
1
|
> どういう理由でHash JoinとNested Loopが別れるか教えて下さい。
|
|
2
2
|
|
|
3
|
-
|
|
3
|
+
リファレンスによれば、それぞれの選択肢で計画し一番コストの低いものを選択するとあります。
|
|
4
|
+
|
|
4
5
|
[51.5. プランナ/オプティマイザ](https://www.postgresql.jp/document/14/html/planner-optimizer.html)
|
|
5
6
|
|
|
6
7
|
以下抜粋
|
|
7
8
|
|
|
9
|
+
> 問い合わせが２つ以上のリレーションの結合を必要とすると、リレーションを結合する計画は、単一のリレーションをスキャンするために全ての実行可能な計画が探し出された後に検討されます。３つの実行可能な結合戦略を示します。
|
|
10
|
+
>
|
|
8
11
|
> ネステッドループ結合： 左側のリレーションの中で見つけられた行ごとに右側のリレーションが1回スキャンされます。 この戦略は実装が簡単ですが、時間がかかる場合があります （とは言っても右側のリレーションがインデックススキャンによってスキャン可能であればよい戦略になります。 右側のインデックススキャンのキーとして左側のリレーションの現在の行の値を使用することができます。）
|
|
9
12
|
>
|
|
10
13
|
> マージ結合： 結合を開始する前に、それぞれのリレーションを結合属性でソートします。 そして、2つのリレーションを並行してスキャンし、一致する行を結合行の形にまとめます。 それぞれのリレーションがたった1回しかスキャンされなくて済むのでこの結合は魅力的です。 要求されるソートは、明示的なソート段階、または、結合キー上のインデックスを使用して適切な順序でリレーションをスキャンすることにより行われます。
|
1
推敲
test
CHANGED
|
@@ -1,4 +1,8 @@
|
|
|
1
|
+
> どういう理由でHash JoinとNested Loopが別れるか教えて下さい。
|
|
2
|
+
|
|
3
|
+
以下リファレンスです。
|
|
1
4
|
[51.5. プランナ/オプティマイザ](https://www.postgresql.jp/document/14/html/planner-optimizer.html)
|
|
5
|
+
|
|
2
6
|
以下抜粋
|
|
3
7
|
|
|
4
8
|
> ネステッドループ結合： 左側のリレーションの中で見つけられた行ごとに右側のリレーションが1回スキャンされます。 この戦略は実装が簡単ですが、時間がかかる場合があります （とは言っても右側のリレーションがインデックススキャンによってスキャン可能であればよい戦略になります。 右側のインデックススキャンのキーとして左側のリレーションの現在の行の値を使用することができます。）
|