このページでは、インデックス スキャン中のキャッシュ認識について説明します。有効にすると、AlloyDB for PostgreSQL クエリ プランナーは、実行開始時に共有バッファで使用可能なインデックス ページとテーブルページの数に基づいて、インデックス スキャンの推定 I/O コストを調整します。最終的なクエリプランは、調整されたプランのコストに基づいて選択されます。これにより、クエリのパフォーマンスが向上し、データベース コストが削減されます。
有効にすると、キャッシュ認識機能が自動的に動作し、共有バッファのヒット状況の変化に応じて調整されます。また、キャッシュ認識は、AlloyDB クエリ プランナーのコスト見積もりを random_page_cost に設定するなど、他のクエリ調整手法と連携できます。
キャッシュ認識を有効にする
AlloyDB インスタンスのキャッシュ認識を有効にするには、alloydb.enable_cache_aware_costing（プレビュー）フラグを on に設定します。また、セッション レベルでフラグを設定し、同じセッション内で実行されるクエリプランに影響を与えることもできます。フラグの設定方法については、インスタンスのデータベース フラグを構成するをご覧ください。
シナリオの例
次のコードサンプルは、完全にウォームアップされた共有バッファ キャッシュで実行されるインデックス スキャン プランを示しています。
explain (analyze, verbose, buffers)
SELECT count(d) FROM t1 WHERE a = 10 AND b > 100 AND c > 100;
------------------ Aggregate (cost=3908.93..3908.94 rows=1 width=8) (actual time=4.128..4.130 rows=1 loops=1)
Output: count(d)
Buffers: shared hit=926
-> Index Scan using idx1 on public.t1 (cost=0.43..3906.49 rows=975 width=2) (actual time=0.143..3.205 rows=919 loops=1)
Output: a, b, c, d
Index Cond: ((t1.a = 10) AND (t1.b > 100) AND (t1.c > 100))
Buffers: shared hit=926
Execution Time: 4.353 ms
この実行中に、I/O 読み取りはありませんでした。キャッシュ認識が有効でない場合、クエリ プランナーはインデックス スキャン クエリ プランに I/O コストを含めます。これにより、インデックス スキャン クエリ プランがシーケンシャル スキャン クエリ プランに劣る結果になる可能性があります。
次のコード スニペットは、キャッシュ認識が有効になっている場合の調整後のクエリプランのコストを示しています。
explain (verbose)
SELECT count(d) FROM t1 WHERE a = 10 AND b > 100 AND c > 100;
------------------ Aggregate (cost=29.93..29.94 rows=1 width=8)
Output: count(d)
-> Index Scan using idx1 on public.t1 (cost=0.43..27.49 rows=975 width=2)
Output: a, b, c, d
Index Cond: ((t1.a = 10) AND (t1.b > 100) AND (t1.c > 100))
同じインデックス スキャン クエリ プランの新しいコスト 27.49 は、以前のコスト 3906.49 よりも大幅に低くなっています。