PolarDB:読み取り先読みおよび事前拡張

ヒープテーブルの読み取り先読み

PostgreSQL では通常、8 KB のページを 1 ページずつバッファープールに読み込みます。しかし、PFS 上ではこのような小規模な読み取りパターンは非効率です。2 ページ以上を読み込む必要がある場合、PolarDB ではそれらを 128 KB の単一読み取りにまとめて処理し、I/O 操作の総数を削減します。

この処理は以下の 4 ステップで実行されます。

1. バッファープールから N 個のバッファーを確保します。

2. N × page size のサイズの隣接したメモリ領域を palloc を使用して確保し、これを p と呼びます。

3. PFS を使用して、ヒープテーブルから N × page size のデータを p に読み込みます。

4. p から N 個のページを N 個のバッファーにコピーします。

その後、これらのページに対する読み取りはバッファープールから直接ヒットするため、追加のディスク I/O は発生しません。

以下の図は、データフローを示しています。

ヒープテーブルの事前拡張

標準 PostgreSQL では、表領域の拡張は 8 KB のページを 1 ページずつ適用・拡張します。バッチ拡張であっても、N ページの拡張には依然として N 回の I/O 操作が必要です。PFS では最小拡張サイズが 4 MB であるため、この方式では過剰な I/O オーバーヘッドが発生します。

ヒープテーブルの事前拡張は、PFS のバルク書き込みインターフェイスを用いて 4 MB 単位でファイルを拡張することで、この問題を解決します。この処理は以下の 3 ステップで実行されます。

1. ファイルシステムの拡張をトリガーせずに、バッファープールから N 個のバッファーを確保します。

2. PFS のファイル書き込みインターフェイスを使用して、ゼロ埋めされたページを 1 回のバッチ書き込みでファイルを拡張します。

3. ページを 1 ページずつ初期化し、利用可能な領域を特定して、事前拡張を終了します。

インデックス作成時の事前拡張

インデックス作成時の事前拡張は、ヒープテーブルの事前拡張と同様のアプローチを採用しますが、インデックスはディスクにフラッシュされる前にバッファープール内で構築されるため、バッファー確保のステップをスキップします。

この処理は以下の 2 ステップで実行されます。

1. PFS のファイル書き込みインターフェイスを使用して、ゼロ埋めされたページを 1 回のバッチ書き込みでファイルを拡張します。

2. バッファープール内で構築されたインデックスページをファイルシステムに書き込みます。

サポートされるインデックスタイプ：B-tree、GIN、GiST、SP-GiST、Bloom。

旧バージョンの PolarDB for PostgreSQL (Compatible with Oracle) では、インデックス作成時の事前拡張は B-tree インデックスのみをサポートしていました。

ヒープテーブルの読み取り先読み

polar_bulk_read_size パラメーターでヒープテーブルの読み取り先読みを制御します。デフォルト値は 128 KB であり、これは PFS に対して最適な値です。128 KB を超えて増加させても、さらなるパフォーマンス向上は見られません。

ヒープテーブルの先読みを無効化するには：

ALTER SYSTEM SET polar_bulk_read_size = 0;
SELECT pg_reload_conf();

デフォルトサイズでヒープテーブルの読み取り先読みを再有効化するには、以下のコマンドを実行します。

ALTER SYSTEM SET polar_bulk_read_size = '128 KB';
SELECT pg_reload_conf();

現在の値を確認するには：

SHOW polar_bulk_read_size;

ヒープテーブルの事前拡張

polar_heap_bulk_extend_size パラメーターでヒープテーブルの事前拡張を制御します。デフォルト値は 4 MB であり、これは PFS に対して最適な値です。4 MB を超えて増加させても、さらなるパフォーマンス向上は見られません。

旧バージョンの PolarDB for PostgreSQL (Compatible with Oracle) では、対応するパラメーターは polar_bulk_extend_size です。

ヒープテーブルの事前拡張を無効化するには、以下のコマンドを実行します。

ALTER SYSTEM SET polar_heap_bulk_extend_size = 0;
SELECT pg_reload_conf();

デフォルトサイズでヒープテーブルの事前拡張を再有効化するには、以下のコマンドを実行します。

ALTER SYSTEM SET polar_heap_bulk_extend_size = '4 MB';
SELECT pg_reload_conf();

現在の値を確認するには：

SHOW polar_heap_bulk_extend_size;

インデックス作成時の事前拡張

polar_index_bulk_extend_size パラメーターでインデックス作成時の事前拡張を制御します。デフォルト値は 4 MB であり、これは PFS に対して最適な値です。4 MB を超えて増加させても、さらなるパフォーマンス向上は見られません。

旧バージョンの PolarDB for PostgreSQL (Compatible with Oracle) では、対応するパラメーターは polar_index_create_bulk_extend_size です。これらのバージョンでは、B-tree インデックスのみがサポートされていました。

インデックスの作成を拡張前に無効化するには：

ALTER SYSTEM SET polar_index_bulk_extend_size = 0;
SELECT pg_reload_conf();

デフォルトサイズでインデックス作成時の事前拡張を再有効化するには、以下のコマンドを実行します。

ALTER SYSTEM SET polar_index_bulk_extend_size = '4 MB';
SELECT pg_reload_conf();

現在の値を確認するには：

SHOW polar_index_bulk_extend_size;

ヒープテーブルの読み取り先読み

400 GB のテーブルにおける VACUUM のパフォーマンス比較：

400 GB のテーブルにおける連続スキャンのパフォーマンス比較：

結論：

• ヒープテーブルの読み取り先読みにより、VACUUM および連続スキャンのパフォーマンスが 2 倍～3 倍に向上します。

• polar_bulk_read_size をデフォルトの 128 KB を超えて増加させても、さらなるパフォーマンス向上は見られません。

ヒープテーブルの事前拡張

400 GB のテーブルにおけるデータロードのパフォーマンス比較：

結論：

• ヒープテーブルの事前拡張により、データロードのパフォーマンスが 2 倍に向上します。

• polar_heap_bulk_extend_size をデフォルトの 4 MB を超えて増加させても、さらなるパフォーマンス向上は見られません。

インデックス作成時の事前拡張

400 GB のテーブルにおけるインデックス作成のパフォーマンス比較：

結論：

• インデックス作成時の事前拡張により、インデックス作成のパフォーマンスが 30 % 向上します。

• polar_index_bulk_extend_size をデフォルトの 4 MB を超えて増加させても、さらなるパフォーマンス向上は見られません。