TECH BLOG
技術ブログ

PostgreSQL 17 のリリース予定

2024/08/08 に PostgreSQL 17 の beta3 がリリースされています。PostgreSQL17自体のリリースは 2024/09 とのことですので、問題がなければ来月には PostgreSQL 17 がリリースされる予定です。

【 PostgreSQL 公式サイト - Roadmap - 】
https://www.postgresql.org/developer/roadmap/

PostgreSQL 17 で新規実装予定の io_combine_limit パラメータ

PostgreSQL 17 の新機能を確認していきますと、増分バックアップの実装やロジカルレプリケーションの機能追加などが目につきます。
パラメータも色々と追加されているようで、気になったのが io_combine_limit というパラメータです。
この io_combine_limit パラメータは、その名の通りディスク IO に関連するパラメータのようです。
具体的に io_combine_limit パラメータがどのような影響を与えるのかは調査中ですが、PostgreSQL 17 では IO のストリーミング機能が新規に実装されているようで、それに関連するパラメータになっている可能性が高いです（io_combine_limitは、この IO ストリーミングで読み書きされたデータを結合する上限を制御している模様です）。

io_combine_limit パラメータの影響

では実際に io_combine_limit パラメータを変動させて、シーケンシャルスキャンとインデックススキャンの実行速度がどのように変動するかを確認してみます。

環境は

• CentOS 7
• PostgreSQL 17 beta3

となります。

検証用の SQL

検証に利用した SQL は下記のようなものとなります。

# シーケンシャルスキャン
SELECT * FROM pgbench_accounts;

# インデックススキャン
SELECT * FROM pgbench_accounts WHERE aid < 1000;

検証結果

上記 SQL を pgbench を利用して 1 分間実行し続けた際の tps を下記にまとめました。
「TPC-B の tps」に関しては、pgbench の標準のテストスクリプトの結果となります。
また、「クライアント数 = 1、ワーカスレッド数 = 1」のパターンと「クライアント数 = 4、ワーカスレッド数 = 8」のパターンで検証しています。

クライアント数 = 1、ワーカスレッド数 = 1

クライアント数 = 4、ワーカスレッド数 = 8

tps なので「数値が大きい方が性能がよい」ことになりますが、上記の結果からは特に io_combine_limit と tps に大きな相関はなさそうに見えます。
強いて言うのであれば、デフォルトの 16 を下回ると若干 tps も落ちているような気がしますが、誤差の範囲内に収まるといえば収まります。

細かい数値の記載は省略しますが、検証中のサーバのディスク IO の負荷についても io_combine_limit の値によって大きく増減しているということはありませんでした。

まとめ

今回検証した限りでは、io_combine_limit が性能に与える影響は小さい、ということで、少し消化不良な感じの検証結果となってしまいました。
検証用の SQL が簡単すぎたのか、データサイズが合わなかったのか、圧縮方式を zstd にした場合にどうなるのか、など確認したいことは諸々あります（今回の検証結果が io_combine_limit のすべてというわけではありません）。
引き続き、情報収集や検証を行いますので、io_combine_limit に関する新たな情報や検証結果が出ましたら、随時、更新する予定です。