PostgreSQL/EPAS13新機能：パラレルVacuumは高速に処理できるのか？

バキュームは、PostgreSQL の管理者を悩ませる主要な問題の１つ「肥大化」の制御に役立つ重要なユーティリティです。可能な限り早く「肥大化」を抑制するために、バキューム処理は速く実行する必要があります。Postgresql13 では、単一のテーブルに作成された複数の索引のバキュームの並列実行を可能にする機能が導入されました。今回は、その並列バキューム機能についてご紹介します。

※当記事はエンタープライズDB社のブログ記事の翻訳の紹介および弊社考察を加えています。

　Dilip Kumar . (2020, Apr, 17). What is Parallel Vacuum in PostgreSQL 13.
　The EDB Blog.
　https://www.enterprisedb.com/postgres-tutorials/what-parallel-vacuum-postgresql-13

PostgreSQL13 の並列バキューム

ユースケース

複数の索引を持つテーブルについて考えてみます。テーブルに対してバキューム処理を実行すると、そのテーブルに対応する索引もバキュームされます。この機能を使用すると、これら全ての索引に対して並行でバキューム処理を実行できます。各索引に対しては、最大で1つのバキュームプロセスで処理が行われます。

並列バキューム機能を有効にする方法

並列度は、ユーザーが指定するかテーブルにあるインデックスの数に基づいて算出されますが、max_parallel_maintenance_workers パラメータを超える場合は並列度が制限されます。また、索引のサイズが min_parallel_index_scan_size パラメータより大きい場合にのみ並列でバキュームが実行されます。

※デフォルトでは、上記全ての要件を満たしている場合にバキュームが並行して実行されます。

動作確認

パラメータ設定

並列バキュームのためのパラメータを次の通り設定します。

パラメータ	設定値
Min_parallel_index_scan_size	512KB
Max_parallel_maintenance_workers	8

テーブルと索引を作成

動作確認用のテーブルと索引を次の通り作成します。

　
　CREATE TABLE pgbench_accounts (
　aid bigint,
　bid bigint,
　abalance bigint,
　filler1 text DEFAULT md5(random()::text),
　filler2 text DEFAULT md5(random()::text),
　filler3 text DEFAULT md5(random()::text),
　filler4 text DEFAULT md5(random()::text),
　filler5 text DEFAULT md5(random()::text),
　filler6 text DEFAULT md5(random()::text),
　filler7 text DEFAULT md5(random()::text),
　filler8 text DEFAULT md5(random()::text),
　filler9 text DEFAULT md5(random()::text),
　filler10 text DEFAULT md5(random()::text),
　filler11 text DEFAULT md5(random()::text),
　filler12 text DEFAULT md5(random()::text)
　);
　 
　INSERT INTO pgbench_accounts select i,i%10,0 FROM
　generate_series(1,100000000) as i;
　 
　CREATE UNIQUE INDEX pgb_a_aid ON pgbench_accounts(aid);
　CREATE INDEX pgb_a_bid ON pgbench_accounts(bid);
　CREATE INDEX pgb_a_abalance ON pgbench_accounts(abalance);
　CREATE INDEX pgb_a_filler1 ON pgbench_accounts(filler1);
　CREATE INDEX pgb_a_filler2 ON pgbench_accounts(filler2);
　CREATE INDEX pgb_a_filler3 ON pgbench_accounts(filler3);
　CREATE INDEX pgb_a_filler4 ON pgbench_accounts(filler4);
　CREATE INDEX pgb_a_filler5 ON pgbench_accounts(filler5);
　CREATE INDEX pgb_a_filler6 ON pgbench_accounts(filler6);
　CREATE INDEX pgb_a_filler7 ON pgbench_accounts(filler7);
　CREATE INDEX pgb_a_filler8 ON pgbench_accounts(filler8);
　CREATE INDEX pgb_a_filler9 ON pgbench_accounts(filler9);
　CREATE INDEX pgb_a_filler10 ON pgbench_accounts(filler10);
　CREATE INDEX pgb_a_filler11 ON pgbench_accounts(filler11);
　CREATE INDEX pgb_a_filler12 ON pgbench_accounts(filler12);

ワークロード

5,000万 (32 * 1.5M) の TRANSACTION を実行します

　
　./pgbench -c32 -j32 -t1500000 -M prepared -f script.sql postgres

上記で実行したスクリプト（script.sql）の内容は次のようになっています。

　
　\set aid random(1, 100000000)
　\set bid random(1, 100000000)
　\set delta random(-5000, 5000)
　BEGIN;
　UPDATE pgbench_accounts SET bid=:bid WHERE aid = :aid;
　END;

動作確認の結果

並列バキュームのパフォーマンスをテストするため、5,000万（vacuum_freeze_min_age）のトランザクションを実行することにより、バキュームが FREEZE の危機に瀕している状況を再現しました。UPDATE 処理によってテーブルとインデックスに大きな肥大化が発生している状況です。

この時点のデータベースの複製を取得してデータベースを同じ状態に戻せるようにし、異なるワーカー数で並列バキュームを実行させ、実行時間の差異を測定しました。結果は次の通りです。

非並列でバキュームを実行した場合は処理に1時間以上かかり、並列バキューム機能を使用するとわずか16分で完了させることができました。ほぼ4倍に高速化されました。

（以上、EDB社ブログ記事より翻訳）

まとめ

EDB/PostgreSQL13 から追加された並列バキューム機能をご紹介しました。複数の索引が作成されたテーブルに対してバキューム処理を実行する場合、並列バキューム機能を使うことでバキューム処理の時間を短縮化する効果が期待できます。索引付きのテーブルのバキューム時間にお悩みの方は、PostgreSQL/EPAS13 にバージョンアップすることをご検討ください。

執筆者情報

保田公貴

2017年に中途入社。Oracle Database、EDB Postgres／PostgreSQL のサポート経験を経て、2020年からバックサポートを担当。DBとアプリケーションを繋ぐミドルウェア製品のスペシャリスト。トレンドな技術は積極的に触れるほど好奇心旺盛。最近はプロアクティブなサポートを目指して粉骨砕身。趣味はボードゲーム。...show more

■本記事の内容について
　本記事に示した定義及び条件は変更される場合があります。あらかじめご了承ください。

■商標に関して
　・Oracle®、Java、MySQL及びNetSuiteは、Oracle、その子会社及び関連会社の米国及びその他の国における登録商標です。
　・Amazon Web Services、AWS、Powered by AWS ロゴ、[およびかかる資料で使用されるその他の AWS 商標] は、Amazon.com, Inc. またはその関連会社の商標です。
　　文中の社名、商品名等は各社の商標または登録商標である場合があります。