はじめに

にゃーん。趣味でポスグレをやっている者だ。

この記事はPostgreSQL 16 全部ぬこ Advent Calendar 2022 15日目の記事です。
今回はREINDEXの性能改善の話を書きます。

概要

項目	内容
タイトル	Avoid overhead open-close indexes (catalog updates)
Topic	Performance
ステータス	commited
Last Modified	2022-11-16
概要	カタログテーブルの更新方式変更によるREINDEXの性能改善

発端となったMLを見るとカタログテーブルのINSERT/UPDATEの処理を効率化することで、REINDEX CONCURRENTRYの処理時間が短縮された、と書いてあるように読めます。

今回は、pgbenchを--unlogged-table -i -s 10で初期化するとpgbench_accounts_pkeyというbtreeインデックスも作成されます。

pgbench_accounts_pkeyのサイズは、PostgreSQL 15/PostgreSQL 16ともに、22,487,040バイトです。

このbtreeインデックス()に対して、REINDEXコマンドをCONCURRENTLYオプションあり/なしで5回実行し、その平均処理時間を比較してみました。

確かにPostgreSQL 16のほうが有意に処理時間が短縮しています。また、CONCURRENTLYオプションがなくても処理時間の短縮効果があるようです。

ついでに、別のインデックス種別(hash)でも効果があるのか試してみました。
pgbench_accountsのaid列に対してhashインデックスを作成します。

CREATE INDEX hash_key ON pgbench_accounts USING hash (aid);

pgbench_accounts_pkeyのサイズは、PostgreSQL 15/PostgreSQL 16ともに、33,570,816バイトです。

で、btreeの測定と同じように5回測定して、その平均値をとってみます。

ハッシュインデックスでも同様に効果があるようです。とはいえ、ハッシュインデックスの場合、インデックス作成時のハッシュ値計算の処理時間のほうが大きいためか、btreeのときほど処理時間比率としては効果が見えにくいかもしれません。

システムカタログの更新処理の効率が上がるだけで、こうした管理コマンドの処理時間の短縮化ができるというのは、ちょっと驚きでした。