PolarDB:実行計画の調整

前提条件

開始する前に、クォータセンターで polar_outline ホワイトリストを申請済みであることを確認してください。[操作] 列で、polardb_pg_polar_outline の横にある [申請] をクリックします。

拡張機能の設定

1. polar_outline 拡張機能を作成します：

   CREATE EXTENSION polar_outline;

   すべての「概要」関数および関係は polar_outline スキーマ内に格納されます。

2. スキーマを検索パスに追加し、「概要」関数をスキーマプレフィックスなしで呼び出せるようにします：

   SET search_path TO "$user", public, polar_outline;

3. 固定計画の適用を有効化します：

   SET polar_outline.use_stored_plan TO ON;

テストデータの準備

以下のステートメントを実行して、t という名前のテーブルを作成し、データを挿入します：

CREATE TABLE t(a INT, b INT);
INSERT INTO t SELECT i, i FROM generate_series(1, 1000) i;

テーブル内のデータを更新して、オプティマイザーが正確な統計情報を使用できるようにします：

ANALYZE t;

PREPARE 文を実行します：

PREPARE test AS SELECT * FROM t WHERE a=$1;

このテストデータは、本セクションの例でのみ使用されます。実際のビジネス要件に応じて、ステートメントを適宜修正してください。

「概要」機能は、キャプチャ対象の実行計画を制御するためのヒントワードを提供します。ステートメントにこのヒントワードを含めて実行すると、そのステートメントの実行計画がキャプチャされます。その後、ヒントワードを含めずに同じステートメントを実行しても、キャプチャされた実行計画に基づいて実行されます。

実行計画のキャプチャと固定

「概要」機能では、PREPARE 文の実行計画のみを固定できます。

状況に応じて、以下のいずれかのキャプチャ方法を選択してください：

SELECT polar_outline_create('EXECUTE test(100)');

 polar_outline_create
----------------------
 t
(1 row)

プラン切り替えによるクエリリライト

PolarDB による SQL クエリのリライト後にパフォーマンスの問題が発生した場合、「概要」機能を用いて SQL クエリをリライトできます。

切り替える 2 つの実行計画は、セマンティクス上等価である必要があります。等価でない計画間で切り替えると、不正な結果セットが返される可能性があります。

以下の例では、ハッシュ結合（Hash Join）を使用する SQL1 の実行計画を、より効率的なネステッドループ結合（Nested Loop）＋ラテラル結合（lateral join）を使用する SQL2 の実行計画に置き換えます。

SQL1 — 元のクエリ：

select t.a, t2.avg_b
from t join (select avg(b) as avg_b, a
             from t2
             group by a) t2
on t2.a = t.a and t.c < $1
order by t.a;

SQL2 — セマンティクスが等価なリライト済みクエリ：

select t.a, t2.avg_b
from t join lateral (select avg(b) as avg_b
                     from t2
                     where t2.a = t.a) as t2
on t.c < $1
order by t.a;

1. テストテーブルを準備します：

   CREATE TABLE t(a int, b int, c int);
   INSERT INTO t SELECT i % 100000, i, i FROM generate_series(1, 1000000) i;
   CREATE TABLE t2 AS SELECT * FROM t;
   CREATE INDEX ON t(c);
   CREATE INDEX ON t2(a);
   ANALYZE t, t2;

2. 両方のクエリの実行計画をキャプチャします：

   PREPARE s1 AS
     SELECT t.a, t2.avg_b FROM t
     JOIN (SELECT avg(b) AS avg_b, a FROM t2 GROUP BY a) t2
     ON t2.a = t.a AND t.c < $1
     ORDER BY t.a;
   
   PREPARE s2 AS
     SELECT t.a, t2.avg_b FROM t
     JOIN LATERAL (SELECT avg(b) AS avg_b FROM t2 WHERE t2.a = t.a) AS t2
     ON t.c < $1
     ORDER BY t.a;
   
   SELECT polar_outline.polar_outline_create('EXECUTE s1(5)');
   SELECT polar_outline.polar_outline_create('EXECUTE s2(5)');

   両方の呼び出しは成功時に t を返します。

3. s1 の実行計画を、s2 の実行計画に切り替えます。入力パラメーターは、それぞれの実行計画の「概要」内 ID です：

   SELECT polar_outline.polar_outline_switch(1, 2);

   EXPLAIN を使用して、s1 がネステッドループ計画を使用していることを確認します：

   EXPLAIN (COSTS FALSE) EXECUTE s1(5);

   切り替え後の期待される出力：

                         QUERY PLAN
   -------------------------------------------------------
    Sort
      Sort Key: t.a
      ->  Nested Loop
            ->  Index Scan using t_c_idx on t
                  Index Cond: (c < $1)
            ->  Aggregate
                  ->  Bitmap Heap Scan on t2
                        Recheck Cond: (a = t.a)
                        ->  Bitmap Index Scan on t2_a_idx
                              Index Cond: (a = t.a)
   (10 rows)

4. s2 の概要を削除します。これは、もはや必要ありません：

   SELECT polar_outline.polar_outline_delete(2);

パラメーター

すべてのパラメーターは polar_outline 名前空間に属します。SET polar_outline.<parameter> TO <value>; を使用して設定します。

注意事項

• 「概要」機能では、PREPARE 文の実行計画のみを固定できます。アドホッククエリはサポートされません。

• ステートメントに埋め込まれたヒントワードにより、その実行に対する計画がキャプチャされます。その後、ヒントワードを含めずに同一のステートメントを実行しても、キャプチャされた計画が引き続き使用されます。

• 例で使用されるテストデータはあくまで説明用です。ワークロードに合わせてテーブル定義およびパラメーター値を調整してください。