

# 共有プランキャッシュの使用
<a name="apg-shared-plan-cache"></a>

## 概要
<a name="apg-shared-plan-cache-overview"></a>

Aurora PostgreSQL は、各クライアント接続ごとに専用のバックエンドプロセスを作成する、ユーザーごとのプロセスモデルを使用します。各バックエンドプロセスでは、プリペアドステートメント用に独自のローカルプランキャッシュが維持されます。これらのキャッシュはプロセス間で共有できないため、多くのプリペアドステートメントを使用するアプリケーションでは、異なるバックエンドプロセス間で重複したキャッシュが作成され、メモリ使用量が増加する可能性があります。

Aurora PostgreSQL バージョン 17.6 以降および 16.10 以降では、共有プランキャッシュ機能が導入されています。この機能を有効にすると、バックエンドプロセスで汎用プランを共有できるため、重複したプラン生成を排除することでメモリ使用量が削減され、パフォーマンスが向上します。

共有プランキャッシュは、キャッシュキーとして次のコンポーネントを使用します。
+ クエリ文字列 (コメントを含む)
+ プランナー関連の GUC パラメータ (`search_path` を含む)
+ ユーザー ID
+ データベース ID

インスタンスの再起動により、共有キャッシュがリセットされます。

## パラメータ
<a name="apg-shared-plan-cache-parameters"></a>

次の表に、共有プランキャッシュ機能を制御するパラメータを示します。


| パラメータ | 説明 | デフォルト | 許可 | 
| --- | --- | --- | --- | 
| apg\$1shared\$1plan\$1cache.enable | 共有プランキャッシュのオン/オフを切り替える | 0 (オフ) | 0、1 | 
| apg\$1shared\$1plan\$1cache.max | キャッシュエントリの最大数 | 200～1,000 (インスタンスサイズによって異なります) | 100–50000 | 
| apg\$1shared\$1plan\$1cache.min\$1size\$1per\$1entry | 共有キャッシュに保存する最小プランサイズ。小規模なプランでは、ローカルキャッシュを使用して OLTP パフォーマンスを最適化します。 | 16 KB | 0～32,768 (KB) | 
| apg\$1shared\$1plan\$1cache.max\$1size\$1per\$1entry | 共有キャッシュの最大プランサイズ。より大きなプランではコスト情報のみが保存されます。 | 256 KB～4 MB (インスタンスサイズによって異なります) | 0～32,768 (KB) | 
| apg\$1shared\$1plan\$1cache.idle\$1generic\$1plan\$1release\$1timeout | アイドルセッションがローカル汎用プランをリリースするまでの時間。値を小さくするとメモリを節約でき、値を大きくするとパフォーマンスが向上する可能性があります。 | 10 秒 | 0～2,147,483,647 (ミリ秒) | 

**注記**  
再起動せずにすべてのパラメータを変更できます。

## ビューと関数のモニタリング
<a name="apg-shared-plan-cache-monitoring"></a>
+ `apg_shared_plan_cache()` – 詳細なキャッシュエントリ情報 (ヒット、有効性、タイムスタンプ) を表示します
+ `apg_shared_plan_cache_stat()` – インスタンスレベルの統計情報 (エビクション、無効化) を表示します
+ `apg_shared_plan_cache_reset()` – `apg_shared_plan_cache()` および `apg_shared_plan_cache_stat()` のすべてのエントリを削除します
+ `apg_shared_plan_cache_remove(cache_key)` – `apg_shared_plan_cache()` から、`cache_key` に一致するエントリを削除します

## 制限
<a name="apg-shared-plan-cache-limitations"></a>
+ プリペアドステートメントでのみ動作し、PL/pgSQL ステートメントはキャッシュされません
+ 一時テーブルまたはカタログテーブルを含むクエリをキャッシュしません
+ RLS (行レベルのセキュリティ) に依存するクエリをキャッシュしません
+ 各レプリカは独自のキャッシュを保持します (レプリカ間の共有はありません)