# Aurora PostgreSQL 管理計画を使用する
<a name="AuroraPostgreSQL.Optimize.UsePlans"></a>

オプティマイザが管理ステートメントに対して取り込んだ計画を使用するには、パラメータ `apg_plan_mgmt.use_plan_baselines` を `true` に設定します。以下はローカルインスタンスの例です。

```
SET apg_plan_mgmt.use_plan_baselines = true;
```

この設定により、アプリケーションの実行中、オプティマイザでは、管理ステートメントごとに最小コストの計画、推奨される計画または承認済み計画が使用されるようになります。

## オプティマイザが選択した計画の分析
<a name="AuroraPostgreSQL.Optimize.UsePlans.AnalyzePlans"></a>

`apg_plan_mgmt.use_plan_baselines` パラメータが `true` に設定されていれば、EXPLAIN ANALYZE SQL ステートメントを使用して、オプティマイザがステートメントを実行する場合に使用する計画を表示することができます。以下に例を示します。

```
EXPLAIN ANALYZE EXECUTE rangeQuery (1,10000);
```

```
                                                    QUERY PLAN           
--------------------------------------------------------------------------
 Aggregate  (cost=393.29..393.30 rows=1 width=8) (actual time=7.251..7.251 rows=1 loops=1)
   ->  Index Only Scan using t1_pkey on t1 t  (cost=0.29..368.29 rows=10000 width=0) (actual time=0.061..4.859 rows=10000 loops=1)
Index Cond: ((id >= 1) AND (id <= 10000))         
         Heap Fetches: 10000
 Planning time: 1.408 ms
 Execution time: 7.291 ms
 Note: An Approved plan was used instead of the minimum cost plan.
 SQL Hash: 1984047223, Plan Hash: 512153379
```

出力には、実行するベースラインの承認済み計画が表示されます。ただし、出力にはより低コストの計画が見つかったことがわかります。この場合、[自動的な計画の取得](AuroraPostgreSQL.Optimize.CapturePlans.md#AuroraPostgreSQL.Optimize.CapturePlans.Automatic) で説明されているように自動計画取り込みをオンにして、この新しい最小コスト計画を取得します。

新しい計画は常に `Unapproved` としてオプティマイザによってキャプチャされます。計画を比較し、それらを承認済み、拒否、または無効に変更するには、`apg_plan_mgmt.evolve_plan_baselines` 関数を使用します。詳細については、「[計画パフォーマンスの評価](AuroraPostgreSQL.Optimize.Maintenance.md#AuroraPostgreSQL.Optimize.Maintenance.EvaluatingPerformance)」を参照してください。

## オプティマイザが実行する計画を選択する方法。
<a name="AuroraPostgreSQL.Optimize.UsePlans.ChoosePlans"></a>

実行計画のコストは、オプティマイザが異なる計画を比較するために行う見積もりです。計画のコストを計算する際、オプティマイザではその計画で必要な CPU や I/O オペレーションなどの要素を考慮します。PostgreSQL クエリプランナーのコスト見積もりの詳細については、PostgreSQL のドキュメントの「[Query Planning](https://www.postgresql.org/docs/current/runtime-config-query.html)」(クエリ計画) を参照してください。

次のイメージは、クエリプラン管理が有効な場合とそうでない場合に、特定の SQL ステートメントに対して計画がどのように選択されるかを示しています。



![\[Aurora PostgreSQL のクエリ計画管理ワークフロー\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/images/aurora-query-plan-mgmt_processing-flow.png)


フローは次のとおりです。

1. オプティマイザでは、SQL ステートメントの最小コストの計画が生成されます。

1. クエリ計画管理が有効ではない場合、オプティマイザの計画が直ちに実行されます (A. オプティマイザの計画を実行)。クエリ計画管理は、`apg_plan_mgmt.capture_plan_baselines` と `apg_plan_mgmt.use_plan_baselines` のパラメータがどちらもデフォルト設定 (それぞれ「off」と「false」) の場合は無効になります。

   それ以外の場合は、クエリ計画管理が有効になります。この場合、SQL ステートメントとそれに対するオプティマイザの計画がさらに評価されてから計画が選択されます。
**ヒント**  
`apg_plan_mgmt` ロールのデータベースユーザーは、必要に応じて計画をプロアクティブに比較する、計画のステータスを変更する、特定の計画を強制的に使用することができます。詳細については、「[Aurora PostgreSQL クエリ計画の改善](AuroraPostgreSQL.Optimize.Maintenance.md)」を参照してください。

1. SQL ステートメントには、過去にクエリ計画管理によって保存された計画が既に含まれている場合があります。計画は、その計画の作成に使用された SQL ステートメントに関する情報とともに `apg_plan_mgmt.dba_plans` に保存されます。計画に関する情報には、そのステータスが含まれます。計画のステータスによって、その計画が使用されているかどうかが次のように決まります。

   1. 計画が SQL ステートメントの保存計画に含まれていない場合は、特定の SQL ステートメントのオプティマイザによってこの特定の計画が初めて生成されたことになります。計画は、キャプチャ計画処理 (4) に送信されます。

   1. 計画が保存されている計画の中にあり、ステータスが「承認済み」または「優先」の場合、その計画が実行されます (A. オプティマイザの計画を実行)。

      計画が保存されている計画に含まれていても、承認済みでも優先でもない場合、計画はキャプチャ計画処理 (4) に送信されます。

1. 特定の SQL ステートメントの計画が初めてキャプチャされると、計画のステータスは常に承認済み (P1) に設定されます。その後、オプティマイザが同じ SQL ステートメントに対して同じ計画を生成すると、その計画のステータスは未承認 (P1\$1n) に変更されます。

   計画がキャプチャされ、ステータスが更新されると、次のステップ (5) で評価が継続されます。

1. 計画の*ベースライン*は、さまざまなステータスでの SQL ステートメントの履歴と計画で構成されています。クエリ計画管理では、計画のベースラインを使用するオプションがオンになっているかどうかによって、次のように計画を選択する際にベースラインを考慮できます。
   + 計画ベースラインの使用は「オフ」の場合、`apg_plan_mgmt.use_plan_baselines` パラメータはデフォルト値 (`false`) に設定されています。計画は、実行前にベースラインと比較されません (A. オプティマイザの計画を実行)。
   + 計画ベースラインの使用が「オン」の場合、`apg_plan_mgmt.use_plan_baselines` パラメータは `true` に設定されます。計画はベースライン (6) を使用してさらに評価されます。

1. この計画は、ベースラインのステートメントの他の計画と比較されます。

   1. オプティマイザの計画がベースラインの計画に含まれる場合、そのステータスがチェックされます (7a)。

   1. オプティマイザの計画がベースラインの計画にない場合、その計画は新規の `Unapproved` 計画としてステートメントの計画に追加されます。

1. 未承認の場合のみ、計画のステータスを確認します。

   1. 計画のステータスが [Unapproved] (未承認) の場合、計画のコストの見積もりは、未承認の実行計画のしきい値に指定されたコストの見積もりと比較されます。
      + 計画のコストの見積もりがしきい値を下回る場合、オプティマイザでは [Unapproved] (未承認) の計画であってもその計画を使用します (A. オプティマイザの計画を実行)。通常、オプティマイザは [Unapproved] (未承認) の計画を実行しません。ただし、`apg_plan_mgmt.unapproved_plan_execution_threshold` パラメータでコストのしきい値を指定すると、オプティマイザは [Unapproved] (未承認) の計画のコストをしきい値と比較します。コストの見積もりがしきい値を下回る場合、オプティマイザは計画を実行します。詳細については、「[apg\$1plan\$1mgmt.unapproved\$1plan\$1execution\$1threshold](AuroraPostgreSQL.Optimize.Parameters.md#AuroraPostgreSQL.Optimize.Parameters.unapproved_plan_execution_threshold)」を参照してください。
      + 計画のコストの見積もりがしきい値を下回っていない場合は、計画の他の属性がチェックされます (8a)。

   1. 計画のステータスが [Unapproved] (未承認) 以外の場合、他の属性が確認されます (8a)。

1. オプティマイザは、無効の計画を使用しません。つまり、`enable` 属性が「f」 (false) に設定されている計画です。また、オプティマイザはステータスが Rejected (拒否) の計画を使用しません。

   オプティマイザは、無効の計画を使用できません。管理計画が依存するオブジェクト (インデックスやテーブルパーティションなど) が削除されると、時間の経過とともに計画が無効になる可能性があります。

   1. ステートメントに有効な推奨計画がある場合、オプティマイザではこの SQL ステートメントに保存されている推奨計画の中から最小コストの計画を選択します。その後、オプティマイザは最小コストの推奨計画を実行します。

   1. そのステートメントに有効化された計画や、有効で推奨される計画がない場合は、次のステップ (9) で評価されます。

1. そのステートメントに有効な推奨計画がある場合、オプティマイザではこの SQL ステートメントに保存されている推奨計画の中から最小コストの計画を選択します。その後、オプティマイザは最小コストの承認済み計画を実行します。

   そのステートメントに有効化された計画や、有効で推奨される計画がない場合、オプティマイザは最小コスト計画 (A. オプティマイザの計画を実行) を使用します。