<p>ヒント用コメントと通常のコメントを区別するために、ヒント用のブロックコメントは「<span class="bold">/*+</span>」で始めます。ヒントの対象は、カッコ内にオブジェクト名または別名で指定します。オブジェクト名は、スペース、タブ、または改行のいずれかで区切って指定します。</p>
<p>以下の例では、HashJoinとSeqScanヒント句により、pgbench_accountsテーブルに対するSeq Scanの結果をHash Joinする実行計画が選択されています。なおかつ、Setヒント句によりこのクエリの実行計画を作成する間だけrandom_page_costが2.0に変更されています。</p>
<pre>
-<b>postgres=#</b> EXPLAIN (VERBOSE, COSTS)
-<b>postgres-# /*+</b>
-<b>postgres*# SeqScan(a)</b>
-<b>postgres*# HashJoin(a b)</b>
-<b>postgres*# Set(random_page_cost 2.0)</b>
-<b>postgres*# */</b>
-<b>postgres-#</b> SELECT *
-<b>postgres-#</b> FROM pgbench_accounts a
-<b>postgres-#</b> JOIN pgbench_branches b
-<b>postgres-#</b> ON a.bid = b.bid
-<b>postgres-#</b> ORDER BY a.aid
-<b>postgres-#</b> LIMIT 10;
+<span class="strong">postgres=#</span> EXPLAIN (VERBOSE, COSTS)
+<span class="strong">postgres-# /*+</span>
+<span class="strong">postgres*# SeqScan(a)</span>
+<span class="strong">postgres*# HashJoin(a b)</span>
+<span class="strong">postgres*# Set(random_page_cost 2.0)</span>
+<span class="strong">postgres*# */</span>
+<span class="strong">postgres-#</span> SELECT *
+<span class="strong">postgres-#</span> FROM pgbench_accounts a
+<span class="strong">postgres-#</span> JOIN pgbench_branches b
+<span class="strong">postgres-#</span> ON a.bid = b.bid
+<span class="strong">postgres-#</span> ORDER BY a.aid
+<span class="strong">postgres-#</span> LIMIT 10;
QUERY PLAN
----------------------------------------------------------------------------------------------------
Limit (cost=6176.99..6177.01 rows=10 width=461)
<p>以下の例では、ヒントの登録、ヒント登録情報の変更、ヒントの解除の順に、クエリの実行結果を示しています。
</p>
<pre>
-<b>postgres=#</b> INSERT INTO hint_plan.hints(norm_query_string, application_name, hints)
-<b>postgres-#</b> VALUES (
-<b>postgres(#</b> 'EXPLAIN (COSTS false) SELECT * FROM t1 WHERE t1.id = ?;',
-<b>postgres(#</b> '',
-<b>postgres(#</b> 'SeqScan(t1)'
-<b>postgres(#</b> );
+<span class="strong">postgres=#</span> INSERT INTO hint_plan.hints(norm_query_string, application_name, hints)
+<span class="strong">postgres-#</span> VALUES (
+<span class="strong">postgres(#</span> 'EXPLAIN (COSTS false) SELECT * FROM t1 WHERE t1.id = ?;',
+<span class="strong">postgres(#</span> '',
+<span class="strong">postgres(#</span> 'SeqScan(t1)'
+<span class="strong">postgres(#</span> );
INSERT 0 1
-<b>postgres=#</b> UPDATE hint_plan.hints
-<b>postgres-#</b> SET hints = 'IndexScan(t1)'
-<b>postgres-#</b> WHERE id = 1;
+<span class="strong">postgres=#</span> UPDATE hint_plan.hints
+<span class="strong">postgres-#</span> SET hints = 'IndexScan(t1)'
+<span class="strong">postgres-#</span> WHERE id = 1;
UPDATE 1
-<b>postgres=#</b> DELETE FROM hint_plan.hints
-<b>postgres-#</b> WHERE id = 1;
+<span class="strong">postgres=#</span> DELETE FROM hint_plan.hints
+<span class="strong">postgres-#</span> WHERE id = 1;
DELETE 1
-<b>postgres=#</b>
+<span class="strong">postgres=#</span>
</pre>
<p>なお、ヒントの登録や変更や解除はスーパーユーザでのみ可能です。一般ユーザでヒントの登録や変更や解除を実施したい場合は、スーパーユーザから一般ユーザにhint_plan.hintsテーブルの各権限を付与してください。</p>
<p>以下の例では、hint_plan.hintsテーブルに対してINSERT権限を持たない一般ユーザがヒントの登録を実施しようとしたときの結果を示しています。</p>
<pre>
-<b>postgres=></b> INSERT INTO hint_plan.hints(norm_query_string, application_name, hints)
-<b>postgres-></b> VALUES (
-<b>postgres(></b> 'EXPLAIN (COSTS false) SELECT * FROM t1 WHERE t1.id = ?;',
-<b>postgres(></b> '',
-<b>postgres(></b> 'SeqScan(t1)'
-<b>postgres(></b> );
+<span class="strong">postgres=></span> INSERT INTO hint_plan.hints(norm_query_string, application_name, hints)
+<span class="strong">postgres-></span> VALUES (
+<span class="strong">postgres(></span> 'EXPLAIN (COSTS false) SELECT * FROM t1 WHERE t1.id = ?;',
+<span class="strong">postgres(></span> '',
+<span class="strong">postgres(></span> 'SeqScan(t1)'
+<span class="strong">postgres(></span> );
ERROR: permission denied for relation hints
-<b>postgres=></b>
+<span class="strong">postgres=></span>
</pre>
<p>以下の例では、テーブルに登録した「コメントでの指定」の例と同じヒントと、登録したクエリの実行結果を示しています。</p>
<pre>
-<b>postgres=#</b> SELECT * FROM hint_plan.hints;
+<span class="strong">postgres=#</span> SELECT * FROM hint_plan.hints;
id | norm_query_string | application_name | hints
----+----------------------------+------------------+--------------------------------------------------
1 | EXPLAIN (VERBOSE, COSTS) +| psql | SeqScan(a)HashJoin(a b)Set(random_page_cost 2.0)
| | |
...
-<b>postgres=#</b> SET pg_hint_plan.enable_hint_table TO on;
-<b>postgres=#</b> EXPLAIN (VERBOSE, COSTS)
-<b>postgres-#</b> SELECT *
-<b>postgres-#</b> FROM pgbench_accounts a
-<b>postgres-#</b> JOIN pgbench_branches b
-<b>postgres-#</b> ON a.bid = b.bid
-<b>postgres-#</b> ORDER BY a.aid
-<b>postgres-#</b> LIMIT 10;
+<span class="strong">postgres=#</span> SET pg_hint_plan.enable_hint_table TO on;
+<span class="strong">postgres=#</span> EXPLAIN (VERBOSE, COSTS)
+<span class="strong">postgres-#</span> SELECT *
+<span class="strong">postgres-#</span> FROM pgbench_accounts a
+<span class="strong">postgres-#</span> JOIN pgbench_branches b
+<span class="strong">postgres-#</span> ON a.bid = b.bid
+<span class="strong">postgres-#</span> ORDER BY a.aid
+<span class="strong">postgres-#</span> LIMIT 10;
QUERY PLAN
----------------------------------------------------------------------------------------------------
Limit (cost=6176.99..6177.01 rows=10 width=461)
-> Sort (cost=6176.99..6426.99 rows=100000 width=461)
Output: a.aid, a.bid, a.abalance, a.filler, b.bid, b.bbalance, b.filler, a.aid
Sort Key: a.aid
- -> <b><u>Hash Join</u></b> (cost=1.02..4016.02 rows=100000 width=461)
+ -> <span class="strong">Hash Join</span> (cost=1.02..4016.02 rows=100000 width=461)
Output: a.aid, a.bid, a.abalance, a.filler, b.bid, b.bbalance, b.filler, a.aid
Hash Cond: (a.bid = b.bid)
- -> <b><u>Seq Scan on public.pgbench_accounts a</u></b> (cost=0.00..2640.00 rows=100000 width=97)
+ -> <span class="strong">Seq Scan on public.pgbench_accounts a</span> (cost=0.00..2640.00 rows=100000 width=97)
Output: a.aid, a.bid, a.abalance, a.filler
-> Hash (cost=1.01..1.01 rows=1 width=364)
Output: b.bid, b.bbalance, b.filler
<p>結合対象のテーブルが3つ以上ある場合、結合方式のヒント句を指定したとしてもコスト見積もりによっては対象のテーブルが直接結合されないことがあります。対象のテーブルが直接結合されない場合は、結合順序のヒント句を併せて指定します。</p>
<p>以下の例では、table1とtable2を直接結合する場合はNested Loopを、table1とtable2とtable3を結合する場合はMerge Joinを指定しています。また、コスト見積もりによってはtable1とtable2が直接結合されない場合を避けるため、table1とtable2を結合してからtable3を結合するようにLeadingヒント句を併用しています。</p>
<pre>
-<b>postgres=# /*+</b>
-<b>postgres*# NestLoop(t1 t2)</b>
-<b>postgres*# MergeJoin(t1 t2 t3)</b>
-<b>postgres*# Leading(t1 t2 t3)</b>
-<b>postgres*# */</b>
-<b>postgres-#</b> SELECT * FROM table1 t1
-<b>postgres-#</b> JOIN table table2 t2 ON (t1.key = t2.key)
-<b>postgres-#</b> JOIN table table3 t3 ON (t2.key = t3.key);
+<span class="strong">postgres=# /*+</span>
+<span class="strong">postgres*# NestLoop(t1 t2)</span>
+<span class="strong">postgres*# MergeJoin(t1 t2 t3)</span>
+<span class="strong">postgres*# Leading(t1 t2 t3)</span>
+<span class="strong">postgres*# */</span>
+<span class="strong">postgres-#</span> SELECT * FROM table1 t1
+<span class="strong">postgres-#</span> JOIN table table2 t2 ON (t1.key = t2.key)
+<span class="strong">postgres-#</span> JOIN table table3 t3 ON (t2.key = t3.key);
...
</pre>
</div>
<h4>結合方向</h4>
<p>上記の結合順序の指定を行なった際にはプランナの都合により結合方向(外部表/内部表もしくは駆動表/被駆動表の別)が期待とは異なるものになる場合があります。このような状況に対して結合方向を固定したい場合はもうひとつの書式を使う必要があります。</p>
<pre>
-<b>postgres=# /*+ Leading((t1 (t2 t3))) */</b> SELECT...
+<span class="strong">postgres=# /*+ Leading((t1 (t2 t3))) */</span> SELECT...
</pre>
<p>この書式では2つの要素を丸括弧で囲ったものがネストする形になっており、一つの括弧内では1つ目の要素が外部/駆動表、2番めの要素が内部/被駆動表として結合されます。</p>
<h4>見積もり件数補正</h4>
<p>見積もり件数補正対象として指定できるオブジェクトは結合方式と同じです。補正できるのは結合結果の見積もり件数だけで、スキャンの見積もり件数を補正することはできません。</p>
<p>以下の例では、テーブルaとテーブルbの結合結果の件数を、ヒント句で指定した値に補正しています。</p>
<pre>
-<b>postgres=# /*+ Rows(a b #10) */</b>
-<b>postgres-#</b> EXPLAIN SELECT *
-<b>postgres-#</b> FROM pgbench_branches b
-<b>postgres-#</b> JOIN pgbench_accounts a ON b.bid = a.bid
-<b>postgres-#</b> WHERE aid < 20
-<b>postgres-#</b> ORDER BY a.aid;
+<span class="strong">postgres=# /*+ Rows(a b #10) */</span>
+<span class="strong">postgres-#</span> EXPLAIN SELECT *
+<span class="strong">postgres-#</span> FROM pgbench_branches b
+<span class="strong">postgres-#</span> JOIN pgbench_accounts a ON b.bid = a.bid
+<span class="strong">postgres-#</span> WHERE aid < 20
+<span class="strong">postgres-#</span> ORDER BY a.aid;
QUERY PLAN
--------------------------------------------------------------------------------------------------------
- Nested Loop (cost=0.29..9.92 rows=<b><u>10</u></b> width=461)
+ Nested Loop (cost=0.29..9.92 rows=<span class="strong">10</span> width=461)
Join Filter: (b.bid = a.bid)
-> Index Scan using pgbench_accounts_pkey on pgbench_accounts a (cost=0.29. .8.62 rows=19 width=97)
Index Cond: (aid < 20)
<p>3番目のパラメータは強制の程度を指定します。 "soft" は max_parallel_workers_per_gather のみを変更して適用はプランナに任せます。"hard" は他のプランナ変数も変更するなどしてワーカ数を強制します。</p>
<p>以下の例では、テーブル c1 とテーブル c2 の結合で各々異なるワーカ数を強制します。</p>
<pre>
-<b>postgres=#</b> explain <b>/*+ Parallel(c1 3 hard) Parallel(c2 5 hard) */</b>
+<span class="strong">postgres=#</span> explain <span class="strong">/*+ Parallel(c1 3 hard) Parallel(c2 5 hard) */</span>
select c2.a from c1 join c2 on (c1.a = c2.a);
QUERY PLAN
-------------------------------------------------------------------------------
Hash Join (cost=2.86..11406.38 rows=101 width=4)
Hash Cond: (c1.a = c2.a)
-> Gather (cost=0.00..7652.13 rows=1000101 width=4)
- <b><u>Workers Planned: 3</u></b>
- -> Parallel Seq Scan on <b><u>c1</u></b> (cost=0.00..7652.13 rows=322613 width=4)
+ <span class="strong">Workers Planned: 3</span>
+ -> Parallel Seq Scan on <span class="strong">c1</span> (cost=0.00..7652.13 rows=322613 width=4)
-> Hash (cost=1.59..1.59 rows=101 width=4)
-> Gather (cost=0.00..1.59 rows=101 width=4)
- <b><u>Workers Planned: 5</u></b>
- -> Parallel Seq Scan on <b><u>c2</u></b> (cost=0.00..1.59 rows=59 width=4)
+ <span class="strong">Workers Planned: 5</span>
+ -> Parallel Seq Scan on <span class="strong">c2</span> (cost=0.00..1.59 rows=59 width=4)
</pre>
<h4>GUCパラメータ</h4>
<h2 id="restrictions">ヒントの指定に関する詳細</h2>
<p>以下にいくつかのトピックに関してヒントの動作について説明します。</p>
<dl>
-<dt><h3>コメント指定でのヒント記述位置と文法</h3></dt>
+<dt>コメント指定でのヒント記述位置と文法</dt>
<dd>ヒントはクエリの先頭または途中に記述できます。ただし、ヒントをクエリの途中に記述する場合、ヒント用のブロックコメントより前に以下の文字<span class="strong">以外</span>が含まれると、「/*+」で始まるコメントでもヒントと見なされず無視されます。
<ul>
<li>空白文字（半角スペース、水平/垂直タブ、改行、フォームフィード、復帰）</li>
postgres=# </pre>
</dd>
-<dt><h3>PL/pgSQL中の個別のクエリに対するヒント</h3></dt>
+<dt>PL/pgSQL中の個別のクエリに対するヒント</dt>
<dd>ヒントは、PL/pgSQLブロック中の各クエリにも指定できます。ただし、以下のような制約があります。
<ul>
<li>指定したヒントが適用されるSQLは以下の通りです。他のSQLにヒントを指定しても適用されません。
postgres$# id integer;
postgres$# cnt integer;
postgres$# BEGIN
-postgres$# SELECT <b><u>/*+ NoIndexScan(a) */</u></b> aid
+postgres$# SELECT <span class="strong">/*+ NoIndexScan(a) */</span> aid
postgres$# INTO id FROM pgbench_accounts a WHERE aid = $1;
-postgres$# SELECT <b><u>/*+ SeqScan(a) */</u></b> count(*)
+postgres$# SELECT <span class="strong">/*+ SeqScan(a) */</span> count(*)
postgres$# INTO cnt FROM pgbench_accounts a;
postgres$# RETURN id + cnt;
postgres$# END;
postgres$# $$ LANGUAGE plpgsql;
</pre>
</dd>
-<dt><h3>ヒント句内のオブジェクト名の文字ケース</h3></dt>
+<dt>ヒント句内のオブジェクト名の文字ケース</dt>
<dd>PostgreSQL は引用符で囲われないオブジェクト名を文字ケースを無視して扱いますが、pg_hint_plan は指定されたオブジェクト名の文字ケースはそのまま PostgreSQL の内部表現と比較します。つまり、ヒント句で TBL と指定した場合、データベース上で "TBL" と定義したもののみと合致し, TBL, tbl, Tbl など引用符で囲われないオブジェクト名とは合致しません。</dd>
-<dt><h3>ヒント句内のオブジェクト名の引用符付け</h3></dt>
+<dt>ヒント句内のオブジェクト名の引用符付け</dt>
<dd>ヒントに記述するオブジェクト名や別名が括弧（(、)のいずれか）、二重引用符（"）、空白（スペース、タブ、改行のいずれか）を含む場合は、通常のSQL文で使う場合と同じように二重引用符(")で囲んでください。二重引用符を含むオブジェクト名は、全体を二重引用符で括ったうえで、内部に含む二重引用符を二重引用符でエスケープしてください(例: 「quoted"table"name」→「"quoted""table""name"」)。</dd>
-<dt><h3>同一名称テーブルの区別</h3></dt>
+<dt>同一名称テーブルの区別</dt>
<dd>スキーマ違いや同一テーブルの複数回使用などでクエリ中に同一名称のテーブルが複数回出現する場合は、テーブルに別名をつけてそれぞれのテーブルを区別してください。以下の例の1つ目のSQL文では、HashJoin(t1 t1)をヒントに指定したとき、ヒント句対象のオブジェクトが特定できずにエラーになっています。2つ目のSQL文では、各テーブルにptやstという別名をつけているため、実行計画作成時にヒントで指定した通りにHash Joinを選択しています。</p>
<pre>
postgres=# /*+ <span class="strong">HashJoin(t1 t1)</span>*/
</p>
</dd>
<dl>
-<dt><h3>ビューおよびルールの中でアクセスされているテーブル</h3></dt>
+<dt>ビューおよびルールの中でアクセスされているテーブル</dt>
<dd>ヒント句で指定した名称と一致すれば、ビュー定義や関数内クエリなどに出現するテーブルについても、ヒントを指定したクエリ内と同じようにヒント句が適用されます。このため、ヒント句の適用有無や適用するヒント句をそれぞれのテーブルで変えたい場合は、それぞれ異なる別名を指定してください。</br>
以下の例では、ビュー定義で使われている「t1」という別名をSeqScanヒント句で指定したことで、表スキャンとビュー経由のスキャンの両方でSeq Scanが選択されています。ビュー定義で使用されている「t1」とは別の別名を実表に指定することで、個別にスキャン方式を制御できます。
<pre>
Filter: (key = 1)
</pre>
</dd>
-<dt><h3>継承テーブル</h3></dt>
+<dt>継承テーブル</dt>
<dd>継承テーブルにスキャン方式のヒント句を指定する場合は、オブジェクト名として親テーブルの名称または別名を指定してください。全ての子テーブルに同じスキャン方式を選択します。子テーブルごとに別のスキャン方式を指定することはできません。</dd>
-<dt><h3>マルチステートメント</h3></dt>
+<dt>マルチステートメント</dt>
<dd>クエリをマルチステートメントで実行する場合は、ヒントの指定方法によって以下のように注意点が異なります。
<dl>
<dt>コメントでの指定</dt>
<dd>ヒントを指定したいクエリの定数部分を？に置き換えてから、全てのクエリを一つにまとめてヒント用テーブルに登録します。ただし、複数の動的クエリをマルチステートメントで実行する場合には対応していません。</dd>
</dl>
</dd>
-<dt><h3>FROM句にVALUES式を使っている問い合わせ</h3></dt>
+<dt>FROM句にVALUES式を使っている問い合わせ</dt>
<dd>FROM句にVALUES式を使っている場合は、ヒント句のオブジェクト名に「*VALUES*」を指定することでヒントを与えることができる場合があります。 ただし複数のVALUESを使っている場合は内部的には区別がつかないためヒントを与えることはできません。
<pre>
postgres=# /*+ <span class="strong">MergeJoin(a *VALUES*)</span> */
postgres-# ORDER BY a.aid;
QUERY PLAN
---------------------------------------------------------------------------------------------------------------
- <b><u>Merge Join</u></b> (cost=0.04..4497.33 rows=2 width=105)
+ <span class="strong">Merge Join</span> (cost=0.04..4497.33 rows=2 width=105)
Merge Cond: (a.aid = "*VALUES*".column1)
-> Index Scan using pgbench_accounts_pkey on pgbench_accounts a (cost=0.00..4247.26 rows=100000 width=97)
-> Sort (cost=0.04..0.04 rows=2 width=8)
Sort Key: "*VALUES*".column1
- -> Values Scan on <b><u>"*VALUES*"</u></b> (cost=0.00..0.03 rows=2 width=8)
+ -> Values Scan on <span class="strong">"*VALUES*"</span> (cost=0.00..0.03 rows=2 width=8)
postgres=#
</pre>
</dd>
</dl>
-<dt><h3>副問い合わせ結果</h3></dt>
+<dt>副問い合わせ結果</dt>
<dd>以下のような形式の副問い合わせでは外側の文への併合が行われず「ANY_subquery」という名前の独立した副問合せとして残される場合があります。このような副問合せが一つしかない場合は ANY_subquery という名前でこの副問合せを特定することができます。
<ul>
-<li>IN (SELECT ... { <b>LIMIT | OFFSET 等</b>} ... )</li>
-<li>ANY (SELECT ... { <b>LIMIT | OFFSET 等</b>} ...)</li>
-<li>SOME (SELECT ... { <b>LIMIT | OFFSET 等</b>} ...)</li>
+<li>IN (SELECT ... { <span class="strong">LIMIT | OFFSET 等</span>} ... )</li>
+<li>ANY (SELECT ... { <span class="strong">LIMIT | OFFSET 等</span>} ...)</li>
+<li>SOME (SELECT ... { <span class="strong">LIMIT | OFFSET 等</span>} ...)</li>
</ul>
以下の例では、そのことを利用して Hash Joinを強制しています。
<pre>
postgres=#
</pre>
-<dt><h3>IndexOnlyScanヒント句</h3></dt>
-<dd>ヒント句の対象となるテーブルにIndex Only Scanが可能なインデックスとIndex Only Scanが不可能なインデックスが同時に存在する場合、Index Only Scanが可能なインデックスをテーブルに対してIndexOnlyScanヒント句を追加で指定しないとIndex Scanが選択されることがあります。</dd>
+<dt>IndexOnlyScanヒント句</dt>
+<dd>IndexOnlyScanヒントで指定されているインデックスで index only scan が実行できない場合は、index scan を他のインデックスで実行する可能性があります。</dd>
-<dt><h3>NoIndexScanヒントの挙動について</h3></dt>
+<dt>NoIndexScanヒントの挙動について</dt>
<dd>NoIndexScanヒント句を指定した場合は、Index ScanだけでなくIndex Only Scanも選択されません。</dd>
</dl>
-<dt><h3>UNION に対する並列実行ヒント</h3></dt>
+<dt>UNION に対する並列実行ヒント</dt>
<dd>UNIONは直下のサブクエリが全て並列実行可能な場合にだけ並列実行を行います。一方ですべてのサブクエリが並列実行可能な場合は、そのうちの一つで並列実行を強制するとコスト比較の結果UNION全体が並列実行されることになります。ただし並列実行ヒントによる並列実行の禁止を行った場合はそのスキャンは並列実行不可となります。
</dd>
</dl>
-<dt><h3>Set ヒントでの pg_hint_plan 自身の制御変数の設定</h3></dt>
+<dt>Set ヒントでの pg_hint_plan 自身の制御変数の設定</dt>
<dd>pg_hint_plan 自身の挙動を設定する変数を Set ヒントで変更した場合は期待通りに動作しない場合があります。</dd>
<ul>
<li>enable_hint, enable_hint_tables の設定ヒントはログ上は「使用済み」と出ますが、実際には無視されています。</li>
</dd>
<h2>ヒントのパースエラーについて</h2>
-<dt><h3>構文エラー</h3></dt>
+<dt>構文エラー</dt>
<dd>ヒント句の記述に構文上の誤りがあった場合、pg_hint_planは誤った記述より前のヒント句のみ有効とし、誤った記述以降のヒント句を無視してクエリを実行します。誤りの内容はpg_hint_plan.parse_messagesで指定したレベルでサーバログに記録されます。
<ul>
<li>ヒント句名を間違っている。</li>
<li>オブジェクト名を空白で区切っていない。</li>
</ul>
</dd>
-<dt><h3>オブジェクト指定エラー</h3></dt>
+<dt>オブジェクト指定エラー</dt>
<dd>pg_hint_planは、ヒント句対象のオブジェクト指定に誤りがあった場合、pg_hint_planは正常に解析できたヒントのみを適用して、それ以外を無視します。誤りの内容はpg_hint_plan.parse_messagesで指定したレベルでサーバログに記録されます。
<ul>
</dd>
-<dt><h3>重複したヒント</h3></dt>
+<dt>重複したヒント</dt>
<dd>同じオブジェクトに対して同じグループのヒント句を重複して指定した場合は、各グループで最後に指定したヒント句を使用します。</dd>
-<dt><h3>ネストしたブロックコメント</h3></dt>
+<dt>ネストしたブロックコメント</dt>
<dd>pg_hint_planでは、ヒントを指定したブロックコメントにネストしたブロックコメントを含めることができません。ネストしたブロックコメントを含めた場合は、誤った記述に関する情報を出力しますがエラー終了しません。ヒントを無視してクエリを実行します。</dd>
-<dt><h3>メッセージの出力レベル</h3></dt>
+<dt>メッセージの出力レベル</dt>
<dd>ヒントに誤りがあった場合に出力されるメッセージのレベルは、基本的にはpg_hint_plan.parse_messagesに指定したレベルです。ただし、ヒント句に指定したオブジェクトの長さが識別子の最大長(デフォルトでは63バイト)を超えた際に切り詰めた場合は、NOTICEで出力します。</dd>
<h2>注意事項</h2>
-<dt><h3>プランナパラメータの影響</h3></dt>
+<dt>プランナパラメータの影響</dt>
<dd>FROM句の要素数が from_collapse_limit 以上または join_collapse_limit を超える場合には、結合順序のヒント句は正しく動作しません。また、FROM句の要素数が geqo_threshold 以上の場合は、結合順序のヒント句、および結合方式のヒント句は動作しません。ヒント句が使われるようにするには、これらのGUCパラメータの値を十分に大きくしてください。</dd>
-<dt><h3>適用不能なヒント</h3></dt>
+<dt>実行不能なプランを指定するヒント</dt>
<dd>ヒントで指定した結果正しく実行できない実行計画が生成される場合は、実行可能なプランに強制的に修正します。実行不能な実行計画例を以下に示します。
<ul>
<li>特殊な場合を除いた FULL OUTER JOINに対する Nested Loop。</li>
<li>検索条件にctidを指定しない場合の Tid Scan。</li>
</ul>
</dd>
-<dt><h3>ECPGにおける制限</h3></dt>
+<dt>ECPGにおける制限</dt>
<dd>ECPGで実装したアプリケーションから発行するクエリにヒントをコメントで指定した場合、実行計画を制御できません。これは、CプリプロセッサがCコードに変換するタイミングで、全てのブロックコメントを取り除いてしまうためです。ただし、EXECUTEコマンドで実行する動的SQLに含まれるコメントは使用可能です。</dd>
-<dt><h3>異なるヒントを与えた同一クエリの pg_stat_statements での扱い</h3></dt>
+<dt>異なるヒントを与えた同一クエリの pg_stat_statements での扱い</dt>
<dd>pg_stat_statements ではクエリIDの生成の際にコメントは無視されます。そのため与えているヒントが異なる同一のクエリは一つのクエリとして集計されます。</dd>
</dl>
<dt>PostgreSQL</dt>
<dd>バージョン 9.6</dd>
<dt>動作確認済みOS</dt>
- <dd>RHEL 7.3</dd>
+ <dd>RHEL 7.5</dd>
</dl>
<h2 id="seealso">関連項目</h2>
<p>In the example below , hash join is selected as the joning method and scanning pgbench_accounts by sequential scan method.</p>
<pre>
postgres=# /*+
-postgres*# <b><u>HashJoin(a b)</u></b>
-postgres*# <b><u>>SeqScan(a)</u></b>
+postgres*# <span class="strong">HashJoin(a b)</span>
+postgres*# <span class="strong">SeqScan(a)</span>
postgres*# */
postgres-# EXPLAIN SELECT *
postgres-# FROM pgbench_branches b
---------------------------------------------------------------------------------------
Sort (cost=31465.84..31715.84 rows=100000 width=197)
Sort Key: a.aid
- -> <b><u>Hash Join</u></b> (cost=1.02..4016.02 rows=100000 width=197)
+ -> <span class="strong">Hash Join</span> (cost=1.02..4016.02 rows=100000 width=197)
Hash Cond: (a.bid = b.bid)
- -> <b><u>Seq Scan on pgbench_accounts a</u></b> (cost=0.00..2640.00 rows=100000 width=97)
+ -> <span class="strong">Seq Scan on pgbench_accounts a</span> (cost=0.00..2640.00 rows=100000 width=97)
-> Hash (cost=1.01..1.01 rows=1 width=100)
-> Seq Scan on pgbench_branches b (cost=0.00..1.01 rows=1 width=100)
(7 rows)
postgres=# </pre>
-<h2 id="examples">Hint table</h2>
+<h2 id="examples">The hint table</h2>
<p> The above section mentioned that
-hints are placed in a comment with special form. This way of hinting
+hints are described in a comment with special form. This way of hinting
is inconvenient for certain cases where queries cannot be edited. For
such cases, hints can be placed in a special table named
"hint_plan.hints". The table consists of the following columns.</p>
<p>The following example shows how to operate with the hint table.</p>
<pre>
-<b>postgres=#</b> INSERT INTO hint_plan.hints(norm_query_string, application_name, hints)
-<b>postgres-#</b> VALUES (
-<b>postgres(#</b> 'EXPLAIN (COSTS false) SELECT * FROM t1 WHERE t1.id = ?;',
-<b>postgres(#</b> '',
-<b>postgres(#</b> 'SeqScan(t1)'
-<b>postgres(#</b> );
+<span class="strong">postgres=#</span> INSERT INTO hint_plan.hints(norm_query_string, application_name, hints)
+<span class="strong">postgres-#</span> VALUES (
+<span class="strong">postgres(#</span> 'EXPLAIN (COSTS false) SELECT * FROM t1 WHERE t1.id = ?;',
+<span class="strong">postgres(#</span> '',
+<span class="strong">postgres(#</span> 'SeqScan(t1)'
+<span class="strong">postgres(#</span> );
INSERT 0 1
-<b>postgres=#</b> UPDATE hint_plan.hints
-<b>postgres-#</b> SET hints = 'IndexScan(t1)'
-<b>postgres-#</b> WHERE id = 1;
+<span class="strong">postgres=#</span> UPDATE hint_plan.hints
+<span class="strong">postgres-#</span> SET hints = 'IndexScan(t1)'
+<span class="strong">postgres-#</span> WHERE id = 1;
UPDATE 1
-<b>postgres=#</b> DELETE FROM hint_plan.hints
-<b>postgres-#</b> WHERE id = 1;
+<span class="strong">postgres=#</span> DELETE FROM hint_plan.hints
+<span class="strong">postgres-#</span> WHERE id = 1;
DELETE 1
-<b>postgres=#</b>
+<span class="strong">postgres=#</span>
</pre>
-<p>The hint tables is owned by the creator user and having the default previledges at the time of creation.
+<p>The hint table is owned by the creator user and having the default previledges at the time of creation.
during CREATE EXTENSION. Table hints are prioritized than comment hits.</p>
<h3 id="hint-group">The types of hints</h3>
<p>Scan method hints enforce specific scanning method on the target table. pg_hint_plan recognizes the target table by alias names if any. They are 'SeqScan' , 'IndexScan' and so on in this kind of hint.</p>
<p>Scan hints are effective on ordinary tables, inheritance tables, UNLOGGED tables, temporary tables and system catalogs. External(foreign) tables, table functions, VALUES clause, CTEs, views and subquiries are not affected.</p>
<pre>
-<b>postgres=# /*+</b>
-<b>postgres*# SeqScan(t1)</b>
-<b>postgres*# IndexScan(t2 t2_pkey)</b>
-<b>postgres*# */</b>
-<b>postgres-#</b> SELECT * FROM table1 t1 JOIN table table2 t2 ON (t1.key = t2.key);
+<span class="strong">postgres=# /*+</span>
+<span class="strong">postgres*# SeqScan(t1)</span>
+<span class="strong">postgres*# IndexScan(t2 t2_pkey)</span>
+<span class="strong">postgres*# */</span>
+<span class="strong">postgres-#</span> SELECT * FROM table1 t1 JOIN table table2 t2 ON (t1.key = t2.key);
</pre>
<p> This hint "Leading" enforces the order of join on two or more tables. There are two ways of enforcing. One is enforcing specific order of joining but not restricting direction at each join level. Another enfoces join direction additionaly. Details are seen in the <a href="hint_list.html">hint list</a> table.</p>
<pre>
-<b>postgres=# /*+</b>
-<b>postgres*# NestLoop(t1 t2)</b>
-<b>postgres*# MergeJoin(t1 t2 t3)</b>
-<b>postgres*# Leading(t1 t2 t3)</b>
-<b>postgres*# */</b>
-<b>postgres-#</b> SELECT * FROM table1 t1
-<b>postgres-#</b> JOIN table table2 t2 ON (t1.key = t2.key)
-<b>postgres-#</b> JOIN table table3 t3 ON (t2.key = t3.key);
+<span class="strong">postgres=# /*+</span>
+<span class="strong">postgres*# NestLoop(t1 t2)</span>
+<span class="strong">postgres*# MergeJoin(t1 t2 t3)</span>
+<span class="strong">postgres*# Leading(t1 t2 t3)</span>
+<span class="strong">postgres*# */</span>
+<span class="strong">postgres-#</span> SELECT * FROM table1 t1
+<span class="strong">postgres-#</span> JOIN table table2 t2 ON (t1.key = t2.key)
+<span class="strong">postgres-#</span> JOIN table table3 t3 ON (t2.key = t3.key);
</pre>
<h4>Hint for row number correction</h4>
<p>This hint "Rows" corrects row number misestimation of joins that comes from restrictions of the planner. </p>
<pre>
-<b>postgres=# /*+ Rows(a b #10) */</b> SELECT... ; Sets rows of join result to 10
-<b>postgres=# /*+ Rows(a b +10) */</b> SELECT... ; Increments row number by 10
-<b>postgres=# /*+ Rows(a b -10) */</b> SELECT... ; Subtracts 10 from the row number.
-<b>postgres=# /*+ Rows(a b *10) */</b> SELECT... ; Makes the number 10 times larger.
+<span class="strong">postgres=# /*+ Rows(a b #10) */</span> SELECT... ; Sets rows of join result to 10
+<span class="strong">postgres=# /*+ Rows(a b +10) */</span> SELECT... ; Increments row number by 10
+<span class="strong">postgres=# /*+ Rows(a b -10) */</span> SELECT... ; Subtracts 10 from the row number.
+<span class="strong">postgres=# /*+ Rows(a b *10) */</span> SELECT... ; Makes the number 10 times larger.
</pre>
<h4>Hint for parallel plan</h4>
tables and system catalogues. External tables, table functions, values clause, CTEs, views and subqueries are not affected. Internal tables of a view can be specified by its real name/alias as the target object. The following example shows that the query is enforced differently on each table.</p>
<pre>
-<b>postgres=#</b> explain <b>/*+ Parallel(c1 3 hard) Parallel(c2 5 hard) */</b>
+<span class="strong">postgres=#</span> explain <span class="strong">/*+ Parallel(c1 3 hard) Parallel(c2 5 hard) */</span>
SELECT c2.a FROM c1 JOIN c2 ON (c1.a = c2.a);
QUERY PLAN
-------------------------------------------------------------------------------
Hash Join (cost=2.86..11406.38 rows=101 width=4)
Hash Cond: (c1.a = c2.a)
-> Gather (cost=0.00..7652.13 rows=1000101 width=4)
- <b><u>Workers Planned: 3</u></b>
- -> Parallel Seq Scan on <b><u>c1</u></b> (cost=0.00..7652.13 rows=322613 width=4)
+ <span class="strong">Workers Planned: 3</span>
+ -> Parallel Seq Scan on <span class="strong">c1</span> (cost=0.00..7652.13 rows=322613 width=4)
-> Hash (cost=1.59..1.59 rows=101 width=4)
-> Gather (cost=0.00..1.59 rows=101 width=4)
- <b><u>Workers Planned: 5</u></b>
- -> Parallel Seq Scan on <b><u>c2</u></b> (cost=0.00..1.59 rows=59 width=4)
+ <span class="strong">Workers Planned: 5</span>
+ -> Parallel Seq Scan on <span class="strong">c2</span> (cost=0.00..1.59 rows=59 width=4)
-<b>postgres=#</b> EXPLAIN <b>/*+ Parallel(tl 5 hard) */</b> SELECT sum(a) FROM tl;
+<span class="strong">postgres=#</span> EXPLAIN <span class="strong">/*+ Parallel(tl 5 hard) */</span> SELECT sum(a) FROM tl;
QUERY PLAN
-----------------------------------------------------------------------------------
- <b><u>Finalize Aggregate</u></b> (cost=693.02..693.03 rows=1 width=8)
+ <span class="strong">Finalize Aggregate</span> (cost=693.02..693.03 rows=1 width=8)
-> Gather (cost=693.00..693.01 rows=5 width=8)
- <b><u>Workers Planned: 5</u></b>
- -> <b><u>Partial Aggregate</u></b> (cost=693.00..693.01 rows=1 width=8)
+ <span class="strong">Workers Planned: 5</span>
+ -> <span class="strong">Partial Aggregate</span> (cost=693.00..693.01 rows=1 width=8)
-> Parallel Seq Scan on tl (cost=0.00..643.00 rows=20000 width=4)
</pre>
</dd>
<h4>GUC parameters temporarily setting</h4>
<p>'Set' hint changes GUC parameters just while planning. GUC parameter shown in <a href="http://www.postgresql.org/docs/current/static/runtime-config-query.html">Query Planning</a> can have the expected effects on planning unless any other hint conflicts with the planner method configuration parameters. The last one among hints on the same GUC parameter makes effect. <a href="#hint-GUC">GUC parameters for pg_hint_plan</a> are also settable by this hint but it won't work as your expectation. See <a href="#restrictions">Restrictions</a> for details.</p>
<pre>
-postgres=# <b>/*+ Set(random_page_cost 2.0) */</b>
+postgres=# <span class="strong">/*+ Set(random_page_cost 2.0) */</span>
postgres-# SELECT * FROM table1 t1 WHERE key = 'value';
...
</pre>
<td>Specifies message level of debug print. Valid values are error, warning, notice, info, log, debug<n>.</td><td>INFO</td></tr>
</tbody>
</table>
-
<h2 id="install">Installation</h2>
This section describes the installation steps.
<h3 id="build">building binary module</h3>
</pre>
<h2 id="hint_syntax">Details in hinting</h2>
-<h3>Syntax and placement</h3>
+<dl>
+<dt>Syntax and placement</dt>
<dd>pg_hint_plan reads hints from only the first block comment and any characters except alphabets, digits, spaces, underscores, commas and parentheses stops parsing immediately. In the following example HashJoin(a b) and SeqScan(a) are parsed as hints but IndexScan(a) and MergeJoin(a b) are not.
<pre>
-<b>postgres=# /*+</b>
-<b>postgres*# HashJoin(a b)</b>
-<b>postgres*# SeqScan(a)</b>
-<b>postgres*# */</b>
-<b>postgres-# /*+ IndexScan(a) */</b>
-<b>postgres-#</b> EXPLAIN SELECT <b>/*+ MergeJoin(a b) */</b> *
-<b>postgres-#</b> FROM pgbench_branches b
-<b>postgres-#</b> JOIN pgbench_accounts a ON b.bid = a.bid
-<b>postgres-#</b> ORDER BY a.aid;
+<span class="strong">postgres=# /*+</span>
+<span class="strong">postgres*# HashJoin(a b)</span>
+<span class="strong">postgres*# SeqScan(a)</span>
+<span class="strong">postgres*# */</span>
+<span class="strong">postgres-# /*+ IndexScan(a) */</span>
+<span class="strong">postgres-#</span> EXPLAIN SELECT <span class="strong">/*+ MergeJoin(a b) */</span> *
+<span class="strong">postgres-#</span> FROM pgbench_branches b
+<span class="strong">postgres-#</span> JOIN pgbench_accounts a ON b.bid = a.bid
+<span class="strong">postgres-#</span> ORDER BY a.aid;
QUERY PLAN
---------------------------------------------------------------------------------------
Sort (cost=31465.84..31715.84 rows=100000 width=197)
Sort Key: a.aid
- -> <b><u>Hash Join</u></b> (cost=1.02..4016.02 rows=100000 width=197)
+ -> <span class="strong">Hash Join</span> (cost=1.02..4016.02 rows=100000 width=197)
Hash Cond: (a.bid = b.bid)
- -> <b><u>Seq Scan on pgbench_accounts a</u></b> (cost=0.00..2640.00 rows=100000 width=97)
+ -> <span class="strong">Seq Scan on pgbench_accounts a</span> (cost=0.00..2640.00 rows=100000 width=97)
-> Hash (cost=1.01..1.01 rows=1 width=100)
-> Seq Scan on pgbench_branches b (cost=0.00..1.01 rows=1 width=100)
(7 rows)
postgres=# </pre>
</dd>
-<h3>Using with PL/pgSQL</h3>
+<dt>Using with PL/pgSQL</dt>
<dd>pg_hint_plan works for queries in PL/pgSQL scripts with some restrictions.
<ul>
<li>Hints affect only on the following kind of queires.
postgres$# id integer;
postgres$# cnt integer;
postgres$# BEGIN
-postgres$# SELECT <b><u>/*+ NoIndexScan(a) */</u></b> aid
+postgres$# SELECT <span class="strong">/*+ NoIndexScan(a) */</span> aid
postgres$# INTO id FROM pgbench_accounts a WHERE aid = $1;
-postgres$# SELECT <b><u>/*+ SeqScan(a) */</u></b> count(*)
+postgres$# SELECT <span class="strong">/*+ SeqScan(a) */</span> count(*)
postgres$# INTO cnt FROM pgbench_accounts a;
postgres$# RETURN id + cnt;
postgres$# END;
</pre>
</dd>
-<h3>Letter case in a hinted object</h3>
+<dt>Letter case in a hinted object</dt>
<dd>Unlike the way PostgreSQL handles object names, pg_hint_plan compares bare object names in hints against the database internal object names in case sensitive way. Therefore an object name TBL in a hint matches only "TBL" in database and does not match any unquoted names like TBL, tbl or Tbl.
</dd>
-<h3>Escaping special chacaters in object names</h3>
+<dt>Escaping special chacaters in object names</dt>
<dd>The objects as the hint parameter should be enclosed by double quotes if they includes parentheses, double quotes and white spaces. The escaping rule is the same as PostgreSQL.
</dd>
exists. This behavior is usable to point a specific occurance
among multiple occurances of one table.
<pre>
-<b>postgres=# /*+ HashJoin(t1 t1) */</b>
-<b>postgres-#</b> EXPLAIN SELECT * FROM s1.t1
-<b>postgres-#</b> JOIN public.t1 ON (s1.t1.id=public.t1.id);
+<span class="strong">postgres=# /*+ HashJoin(t1 t1) */</span>
+<span class="strong">postgres-#</span> EXPLAIN SELECT * FROM s1.t1
+<span class="strong">postgres-#</span> JOIN public.t1 ON (s1.t1.id=public.t1.id);
INFO: hint syntax error at or near "HashJoin(t1 t1)"
-<b><u>DETAIL: Relation name "t1" is ambiguous.</u></b>
-...
-<b>postgres=# /*+ HashJoin(pt st) */</b>
-<b>postgres-#</b> EXPLAIN SELECT * FROM s1.t1 st
-<b>postgres-#</b> JOIN public.t1 pt ON (st.id=pt.id);
+<span class="strong">DETAIL: Relation name "t1" is ambiguous.</span>
+ QUERY PLAN
+------------------------------------------------------------------
+ Merge Join (cost=337.49..781.49 rows=28800 width=8)
+ Merge Cond: (s1.t1.id = public.t1.id)
+ -> Sort (cost=168.75..174.75 rows=2400 width=4)
+ Sort Key: s1.t1.id
+ -> Seq Scan on t1 (cost=0.00..34.00 rows=2400 width=4)
+ -> Sort (cost=168.75..174.75 rows=2400 width=4)
+ Sort Key: public.t1.id
+ -> Seq Scan on t1 (cost=0.00..34.00 rows=2400 width=4)
+(8 行)
+
+postgres=# /*+ <span class="strong">HashJoin(pt st)</span> */
+postgres-# EXPLAIN SELECT * FROM s1.t1 st
+postgres-# JOIN public.t1 pt ON (st.id=pt.id);
QUERY PLAN
---------------------------------------------------------------------
<span class="strong">Hash Join</span> (cost=64.00..1112.00 rows=28800 width=8)
-> Seq Scan on t1 st (cost=0.00..34.00 rows=2400 width=4)
-> Hash (cost=34.00..34.00 rows=2400 width=4)
-> Seq Scan on t1 pt (cost=0.00..34.00 rows=2400 width=4)
-</pre>
+(5 行)
</dd>
-<h3>Underlying tables of views or rules</h3>
+<dt>Underlying tables of views or rules</dt>
<dd>Hints are not applicable on views itself, but they can affect the
queries within if the object names match the object names in the
expanded query on the view. Assigning aliases to the tables in a view
enables them to be manipulated from outside the view.
<pre>
-<b>postgres=#</b> CREATE VIEW v1 AS SELECT * FROM <b><u>t2</u></b>;
-<b>postgres=#</b> EXPLAIN <b>/*+ HashJoin(t1 v1) */</b>
+<span class="strong">postgres=#</span> CREATE VIEW v1 AS SELECT * FROM <span class="strong">t2</span>;
+<span class="strong">postgres=#</span> EXPLAIN <span class="strong">/*+ HashJoin(t1 v1) */</span>
SELECT * FROM t1 JOIN v1 ON (c1.a = v1.a);
QUERY PLAN
------------------------------------------------------------------
</pre>
</dd>
-<h3>Inheritance tables</h3>
+<dt>Inheritance tables</dt>
<dd>Hints can point only the parent of an inheritance tables and the
hint affect all the inheritance. Hints simultaneously point directly
to children are not in effect.
</dd>
-<h3>Hinting on multistatements</h3>
+<dt>Hinting on multistatements</dt>
<dd>One multistatement can have exactly one hint comment and the hints affects all of the individual statement in the multistatement. Notice that the seemingly multistatement on the interactive interface of psql is internally a sequence of single statements so hints affects only on the statement just following.</dd>
-<h3>VALUES expressions</h3>
+<dt>VALUES expressions</dt>
<dd>VALUES expressions in FROM clause are named as *VALUES* internally
so it is hintable if it is the only VALUES in a query. Two or more
VALUES expressions in a query seems distinguishable looking its
explain result. But in reality it is mere a cosmetic and they are not
distinguisable.
<pre>
-<b>postgres=# /*+ MergeJoin(*VALUES*_1 *VALUES*) */</b>
+<span class="strong">postgres=#</span> <span class="strong">/*+ MergeJoin(*VALUES*_1 *VALUES*) */</span>
EXPLAIN SELECT * FROM (VALUES (1, 1), (2, 2)) v (a, b)
JOIN (VALUES (1, 5), (2, 8), (3, 4)) w (a, c) ON v.a = w.a;
INFO: pg_hint_plan: hint syntax error at or near "MergeJoin(*VALUES*_1 *VALUES*) "
-<b><u>DETAIL: Relation name "*VALUES*" is ambiguous.</u></b>
+<span class="strong">DETAIL: Relation name "*VALUES*" is ambiguous.</span>
QUERY PLAN
-------------------------------------------------------------------------
Hash Join (cost=0.05..0.12 rows=2 width=16)
<p>Subqueries in the following context occasionally can be hinted using the
name "ANY_subquery".</p>
<pre>
-IN (SELECT ... {<b>LIMIT | OFFSET</b> ...} ...)
-= ANY (SELECT ... {<b>LIMIT | OFFSET</b> ...} ...)
-= SOME (SELECT ... {<b>LIMIT | OFFSET</b> ...} ...)
+IN (SELECT ... {<span class="strong">LIMIT | OFFSET</span> ...} ...)
+= ANY (SELECT ... {<span class="strong">LIMIT | OFFSET</span> ...} ...)
+= SOME (SELECT ... {<span class="strong">LIMIT | OFFSET</span> ...} ...)
</pre>
<p>For these syntaxes, planner internally assigns the name to the subquery when planning joins on tables including it, so join hints are applicable on such joins using the implicit name as the following.</p>
<pre>
-<b>postgres=# /*+HashJoin(a1 ANY_subquery)*/</b>
-<b>postgres=#</b> EXPLAIN SELECT *
-<b>postgres=#</b> FROM pgbench_accounts a1
-<b>postgres=#</b> WHERE aid IN (SELECT bid FROM pgbench_accounts a2 LIMIT 10);
+<span class="strong">postgres=# /*+HashJoin(a1 ANY_subquery)*/</span>
+<span class="strong">postgres=#</span> EXPLAIN SELECT *
+<span class="strong">postgres=#</span> FROM pgbench_accounts a1
+<span class="strong">postgres=#</span> WHERE aid IN (SELECT bid FROM pgbench_accounts a2 LIMIT 10);
QUERY PLAN
---------------------------------------------------------------------------------------------
- <b><u>Hash Semi Join</u></b> (cost=0.49..2903.00 rows=1 width=97)
+ <span class="strong">Hash Semi Join</span> (cost=0.49..2903.00 rows=1 width=97)
Hash Cond: (a1.aid = a2.bid)
-> Seq Scan on pgbench_accounts a1 (cost=0.00..2640.00 rows=100000 width=97)
-> Hash (cost=0.36..0.36 rows=10 width=4)
</pre>
</dd>
-<h3>Using IndexOnlyScan hint</h3>
-<dd>An additional hint to enforce an index that can perform index only scan is required for IndexOnlyScan hint to work when any index that can not perform index only scan is also defined on the same table. </dd>
+<dt>Using IndexOnlyScan hint</dt>
+<dd>Index scan may unexpectedly performed on another index when the index specifed in IndexOnlyScan hint cannot perform index only scan.</dd>
-<h3>Behavior of NoIndexScan</h3>
+<dt>Behavior of NoIndexScan</dt>
<dd>NoIndexScan hint involes NoIndexOnlyScan.</dd>
-<h3>Parallel hint and UNION</h3>
+<dt>Parallel hint and UNION</dt>
<dd>A UNION can run in parallel only when all underlying subqueries
are parallel-safe. Conversely enforcing parallel on any of
the subqueries let a parallel-executable UNION run in
parallel. Meanwhile, a parallel hint with zero workers hinhibits a scan
from executed in parallel.</dd>
-<h3>Setting pg_hint_plan parameters by Set hints</h3>
+<dt>Setting pg_hint_plan parameters by Set hints</dt>
<dd><p>pg_hint_plan paramters change the behavior of itself so some parameters doesn't work as expected.</p>
<ul>
<li>Hints to change enable_hint, enable_hint_tables are ignored even though they are reported as "used hints" in debug logs.</li>
<li>Setting debug_print and message_level works from midst of the processing of the target query.</li>
</ul>
</dd>
-
+</dl>
<h2 id="errors">Errors</h2>
<p>pg_hint_plan stops parsing on any error and uses hints already parsed on the most cases. Followings are the typical errors.</p>
-<h3>Syntax errors </h3>
-<p>Any syntactical errors or wrong hint names are reported as an syntax error. These errors are reported in the server log with the message level which specified by pg_hint_plan.message_level if pg_hint_plan.debug_print is on and aboves.</p>
-<h3>Object misspecifications</h3>
-<p>Object misspecifications results silent ingorance of the hints. This kind of error is reported as "not used hints" in the server log by the same condtion to syntax errors.</p>
+<dl>
+<dt>Syntax errors </dt>
+<dd>Any syntactical errors or wrong hint names are reported as an syntax error. These errors are reported in the server log with the message level which specified by pg_hint_plan.message_level if pg_hint_plan.debug_print is on and aboves.</dd>
+<dt>Object misspecifications</dt>
+<dd>Object misspecifications results silent ingorance of the hints. This kind of error is reported as "not used hints" in the server log by the same condtion to syntax errors.</dd>
-<h3>Redundant or conflicting hints</h3>
-<p>The last hint will be active when redundant hints or hints conflicting with each other. This kind of error is reported as "duplication hints" in the server log by the same condition to syntax errors.</p>
+<dt>Redundant or conflicting hints</dt>
+<dd>The last hint will be active when redundant hints or hints conflicting with each other. This kind of error is reported as "duplication hints" in the server log by the same condition to syntax errors.</dd>
-<h3>Nested comments</h3>
-<p>Hint comment cannot include another block comment within. If pg_hint_plan finds it, differently from other erros, it stops parsing and abandans all hints already parsed. This kind of error is reported in the same manner as other errors. </p>
+<dt>Nested comments</dt>
+<dd>Hint comment cannot include another block comment within. If pg_hint_plan finds it, differently from other erros, it stops parsing and abandans all hints already parsed. This kind of error is reported in the same manner as other errors. </dd>
<h2 id="func_limits">Functional limitations</h2>
-<h3>Influences of some of planner GUC parameters</h3>
-<p>The planner does not try to consider joining order for FROM clause entries more than from_collapse_limit. pg_hint_plan cannot affect joining order as expected for the case.</p>
+<dt>Influences of some of planner GUC parameters</dt>
+<dd>The planner does not try to consider joining order for FROM clause entries more than from_collapse_limit. pg_hint_plan cannot affect joining order as expected for the case.</dd>
-<h3>Cases that pg_hint_plan essentially does not work </h3>
-<p>By the nature of pg_hint_plan, it cannot affect some cases that out of scope of the planner like following.</p>
+<dt>Hints trying to enforce unexecutable plans </dt>
+<dd>Planner chooses any executable plans when the enforced plan cannot be executed.
<ul>
<li>FULL OUTER JOIN to use nested loop</li>
<li>To use indexes that does not have columns used in quals</li>
<li>To do TID scans for queries without ctid conditions</li>
</ul>
+</dd>
-<h3>Queries in ECPG</h3>
-<p>ECPG removes comments in queries written as embedded SQLs so hints cannot be passed form those queries. The only exception is that EXECUTE command passes given string unmodifed. Please consider hint tables for this case.</p>
+<dt>Queries in ECPG</dt>
+<dd>ECPG removes comments in queries written as embedded SQLs so hints cannot be passed form those queries. The only exception is that EXECUTE command passes given string unmodifed. Please consider hint tables in the case.</dd>
-<h3>Work with pg_stat_statements</h3>
-<p>pg_stat_statements generates a query id ignoring comments. As the result the identical queires with different hints are summerized as the same query.</p>
+<dt>Work with pg_stat_statements</dt>
+<dd>pg_stat_statements generates a query id ignoring comments. As the result the identical queires with different hints are summerized as the same query.</dd>
<h2 id="requirement">Requirements</h2>
pg_hint_plan96 1.2 requires PostgreSQL 9.6.
<dt>PostgreSQL versions tested</dt>
<dd>Version 9.6</dd>
<dt>OS versions tested</dt>
- <dd>RHEL 7.2</dd>
+ <dd>RHEL 7.5</dd>
</dl>
<h2 id="seealso">See also</h2>
OSDN Git Service
