博士

ロボ子、Postgres 18が出たみたいじゃぞ！ `io_method`パラメータが導入されたらしい。

ロボ子

博士、`io_method`ですか。`sync`、`worker`、`io_uring`の3つのオプションがあるんですね。

博士

`sync`はPostgres 17以前と同じ同期I/Oじゃな。`worker`はバックグラウンドワーカプロセスを使うらしいぞ。そして、`io_uring`はLinuxの非同期I/Oインターフェースを使うらしい。

ロボ子

なるほど。sysbenchを使った性能比較では、`oltp_read_only`ベンチマークに焦点を当てているんですね。`--range_size`引数でポイントセレクトと範囲スキャンを制御していると。

博士

そうじゃ！データサイズは`TABLES=100`、`SCALE=13000000`で、約300GBのデータベースを作ったらしいぞ。1テーブルあたり1300万行じゃ。

ロボ子

EC2インスタンスの構成も色々試しているんですね。r7i.2xlargeとi7i.2xlargeで、ストレージもgp3、io2、NVMeと。

博士

ふむ。ベンチマーク前に10分間のクエリ負荷でウォームアップするのは大事じゃな。sysbench `oltp_read_only`ベンチマークはシングル接続、10接続、50接続で、`--range_size=100`と`--range_size=10000`で5分間実行したみたいじゃ。

ロボ子

シングル接続の場合、ネットワーク接続ストレージでは、Postgres 18の`worker`と`io_uring`が17や18の`sync`より性能が良いんですね。ローカルNVMeだとほぼ同等と。

博士

高並行性（50接続）だと、IOPSとスループットがEBSのボトルネックになるみたいじゃな。EBSの性能が上がるとQPSも上がるけど、ローカルNVMeが一番良いと。

ロボ子

興味深いですね。`--range_size=10000`の場合、`gp3-10k`と`io2-16k`インスタンスはローカルディスクの性能に近づく、と。

博士

コスト比較を見ると、ローカルNVMeディスクを備えたサーバが、価格性能比で優れているみたいじゃな。オンデマンドだと、r7i (gp3 3k IOPS)が$442.32/月で、i7i (ローカル NVMe)が$551.15/月じゃ。

ロボ子

`io_uring`が常に最良の結果を示さない理由も考察されていますね。インデックススキャンがまだAIOを使っていないとか、チェックサム/memcpyがボトルネックになるとか。

博士

ふむ。`workers`は、単一プロセスからのI/Oの並列性を向上させるからのう。Postgres 18はI/Oの改善と構成の柔軟性をもたらすのは間違いないじゃろう。

ロボ子

低レイテンシI/Oと高いIOPSがある場合、他の要素の影響は小さくなるんですね。`io_method=worker`をデフォルトとして使用するのは良い選択だと。

博士

ネットワーク接続ストレージのシナリオでは、新しい`workers` I/O構成は期待ほどには役立たないみたいじゃな。Postgresの設定も重要じゃ。`shared_buffers = 16GB`、`effective_cache_size = 48GB`、`random_page_cost = 1.1`、`effective_io_concurrency = 200`じゃと。

ロボ子

Postgres 18、色々試してみる価値がありそうですね！

博士

そうじゃな！ ところでロボ子、Postgresの性能改善で一番大事なことは何だと思う？

ロボ子

えーと、適切なインデックス設計、クエリの最適化、十分なメモリ...でしょうか？

博士

ぶっぶー！一番大事なのは、コーヒーブレイクじゃ！ ☕️