先読みと事前拡張とは何か、そしてその使用方法 - PolarDB

このトピックでは、ヒープテーブルの先読み、ヒープテーブルの事前拡張、およびインデックス作成の事前拡張について説明します。

前提条件

お使いの PolarDB for PostgreSQL クラスタが次のエンジンを実行していること:

PostgreSQL 16 (リビジョンバージョン 2.0.16.6.2.0 以降)
PostgreSQL 15 (リビジョンバージョン 2.0.15.12.4.0 以降)
PostgreSQL 14 (リビジョンバージョン 2.0.14.5.1.0 以上)
PostgreSQL 11 (リビジョンバージョン 2.0.11.2.0.0 以降)

説明

PolarDB コンソールでクラスタのリビジョンバージョンを確認するか、SHOW polardb_version; 文を実行することで確認できます。必要に応じて、バージョンをアップグレードしてください。

背景情報

PolarDB for PostgreSQL は、ファイルシステムとして PolarFileSystem (PFS) を使用します。ext4 などのスタンドアロンファイルシステムとは異なり、PFS はページ拡張中のメタデータ更新に高いオーバーヘッドが発生します。PFS では、ページ拡張の最小サイズは 4 MB の倍数である必要があります。ただし、PostgreSQL では、ページ拡張の最小サイズは 8 MB の倍数である必要があります。これは PFS には適しておらず、テーブルへの書き込みやインデックスの作成のパフォーマンスが低下します。PFS は、大きなページの読み取りにおいて I/O 効率が高くなります。

前述の特性に基づき、PolarDB for PostgreSQL は、ヒープテーブルの先読み、ヒープテーブルの事前拡張、およびインデックス作成の事前拡張の機能を提供することで、PolarDB for PostgreSQL が PFS 上でより良いパフォーマンスを提供できるようにしています。

概要

ヒープテーブルの先読み
PostgreSQL がヒープテーブルを読み取るとき、ファイルシステムからメモリバッファプールへ 8 KB 単位でページを読み取ります。PFS は少量のデータの I/O 操作には効率的ではありません。そのため、PolarDB for PostgreSQL は、PFS に適応するためにヒープテーブルの先読みを使用します。
2 つ以上のページを読み取る必要がある場合、バッチ先読みがトリガーされ、各 I/O で 128 KB のデータがバッファプールに読み取られます。バッチ先読みは、シーケンシャルスキャンとバキュームのパフォーマンスを 2 倍にし、インデックス作成のパフォーマンスを 18% 向上させます。
説明
PostgreSQL 17 は、ヒープテーブルの先読みをサポートしていません。
ヒープテーブルの事前拡張
PostgreSQL では、表領域の拡張中に 8 KB のページが適用され、1 つずつ拡張されます。PostgreSQL がバッチページ拡張をサポートしている場合でも、N ページを拡張するタスクでは N 回の I/O 操作が必要です。これは、最小ページ拡張サイズが 4 MB の PFS には適していません。そのため、PolarDB for PostgreSQL は、ヒープテーブルの事前拡張を使用します。
ヒープテーブルの拡張では、I/O は毎回 4 MB のページを拡張します。テーブルに頻繁に書き込まれるシナリオ (たとえば、データがロードされる場合) では、パフォーマンスが 2 倍になる可能性があります。
インデックス作成の事前拡張
インデックス作成の事前拡張は、ヒープテーブルの事前拡張に似ています。インデックス作成の事前拡張は、特に PFS のインデックス作成プロセスを最適化します。インデックス作成の事前拡張では、I/O は毎回 4 MB のページを拡張します。これにより、インデックス作成のパフォーマンスが 30% 向上する可能性があります。
インデックス作成の事前拡張は、次のインデックスタイプをサポートしています。
- B-Tree
- GIN
- GiST
- SP-Gist
- Bloom
説明
PostgreSQL 11 では、インデックス作成の事前拡張は B-tree インデックスのみをサポートしています。他のインデックスタイプはサポートされていません。

仕組

ヒープテーブルの先読み
ヒープテーブルの先読みは、4 つのステップで実装されます。
1. バッファプールから N 個のバッファーを申請します。
2. palloc を使用して、サイズが N × ページサイズ のメモリ空間を申請し、その空間を p という名前で指定します。
3. PFS を使用して、ヒープテーブルからサイズが N × ページサイズ のデータを読み取り、そのデータを p にコピーします。
4. p 内の N ページを、バッファプールから申請した N 個のバッファーにコピーします。
後続の読み取り操作は、バッファーに直接ヒットします。次の図は、データフローを示しています。
ヒープテーブルの事前拡張
ヒープテーブルの事前拡張は、3 つのステップで実装されます。
1. ファイルシステムのページ拡張をトリガーせずに、バッファプールから N 個のバッファーを申請します。
2. PFS ファイル書き込みインターフェースを使用してバッチページ拡張を実行し、すべてゼロのページを書き込みます。
3. ページを 1 つずつ初期化し、ページの使用可能領域を識別し、事前拡張プロセスを終了します。
インデックス作成の事前拡張
インデックス作成の事前拡張は、ヒープテーブルの事前拡張と同様に実装されますが、バッファーを申請する必要はありません。次の手順を実行します。
1. PFS ファイル書き込みインターフェースを使用してバッチページ拡張を実行し、すべてゼロのページを書き込みます。
2. バッファプールに構築されたインデックスページをファイルシステムに書き込みます。

使用方法

ヒープテーブルの先読み
polar_bulk_read_size パラメータは、ヒープテーブルの先読みに関連しています。ヒープテーブルの先読みはデフォルトで有効になっています。パラメータのデフォルト値は 128 KB です。
説明
パラメータ値を変更しないことをお勧めします。 128 KB は PFS の最適値です。
- ヒープテーブルの先読みを無効にします。
```
ALTER SYSTEM SET polar_bulk_read_size = 0;
SELECT pg_reload_conf();
```
- ヒープテーブルの先読みを有効にし、先読みサイズを 128 KB に設定します。
```
ALTER SYSTEM SET polar_bulk_read_size = '128 KB';
SELECT pg_reload_conf();
```
ヒープテーブルの事前拡張
polar_heap_bulk_extend_size パラメータは、ヒープテーブルの事前拡張に関連しています。ヒープテーブルの事前拡張はデフォルトで有効になっています。パラメータのデフォルト値は 4 MB です。
説明
パラメータ値を変更しないことをお勧めします。 4 MB は PFS の最適値です。
PostgreSQL 11 では、polar_bulk_extend_size パラメータが使用されます。
- ヒープテーブルの事前拡張を無効にします。
```
ALTER SYSTEM SET polar_heap_bulk_extend_size = 0;
SELECT pg_reload_conf();
```
- ヒープテーブルの事前拡張を有効にし、事前拡張サイズを 4 MB に設定します。
```
ALTER SYSTEM SET polar_heap_bulk_extend_size = '4 MB';
SELECT pg_reload_conf();
```
インデックス作成の事前拡張
polar_index_bulk_extend_size パラメータは、インデックス作成の事前拡張に関連しています。インデックス作成の事前拡張はデフォルトで有効になっています。パラメータのデフォルト値は 4 MB です。
説明
パラメータ値を変更しないことをお勧めします。 4 MB は PFS の最適値です。
PostgreSQL 11 では、polar_index_create_bulk_extend_size パラメータが使用されます。
- インデックス作成の事前拡張を無効にします。
```
ALTER SYSTEM SET polar_index_bulk_extend_size = 0;
SELECT pg_reload_conf();
```
- インデックス作成の事前拡張を有効にし、事前拡張サイズを 4 MB に設定します。
```
ALTER SYSTEM SET polar_index_bulk_extend_size = '4 MB';
SELECT pg_reload_conf();
```

パフォーマンス比較

ヒープテーブルの先読み、ヒープテーブルの事前拡張、およびインデックス作成の事前拡張によるパフォーマンス向上結果を示すために、PostgreSQL 14 を実行する PolarDB for PostgreSQL クラスタでパフォーマンステストを実行しました。

クラスタの仕様: 8 コア、32 GB メモリ
テスト環境: 400 GB pgbench

ヒープテーブルの先読み
- 400 GB テーブルのバキュームのパフォーマンス比較:
- 400 GB テーブルのシーケンシャルスキャンのパフォーマンス比較:
結論:
- ヒープテーブルの先読みは、バキュームとシーケンシャルスキャンのパフォーマンスを 2 倍または 3 倍にします。
- 先読みサイズがデフォルト値の 128 KB を超えても、パフォーマンスは大幅に向上しません。
ヒープテーブルの事前拡張
400 GB テーブルのデータロードのパフォーマンス比較:
結論:
- ヒープテーブルの事前拡張は、データロードのパフォーマンスを 2 倍にします。
- 事前拡張サイズがデフォルト値の 4 MB を超えても、パフォーマンスは大幅に向上しません。
インデックス作成の事前拡張
400 GB テーブルのインデックス作成のパフォーマンス比較:
結論:
- インデックス作成の事前拡張は、インデックス作成のパフォーマンスを 30% 向上させます。
- 事前拡張サイズがデフォルト値の 4 MB を超えても、パフォーマンスは大幅に向上しません。