概要
- pgrust v0.2がリリースされ、パフォーマンスが大幅に向上
- OLTPベンチマークでPostgresより30%高速化、分析系ベンチマークで300倍の速度を実現
- クエリエンジンの最適化が主な要因
- Postgresの歴史的な設計が現代ハードウェアに合わなくなっていることを解説
- 最適化手法（バッチ処理、オペレーターフュージョン、SIMD）を紹介
pgrust v0.2のパフォーマンス革命
- pgrust v0.2 がリリースされ、前バージョン比で 10倍の高速化 を達成
- OLTPベンチマーク ではPostgresより 30%高速、Clickbench（分析系ベンチマーク）では Postgresの300倍の速度 を記録
- Clickhouse をも上回るパフォーマンスを実現
クエリエンジンの最適化
- パフォーマンス向上の鍵は クエリエンジン の改良
- pgrustのクエリエンジン単体で 10倍の高速化 を実現
- Postgresが遅い理由は 1980年代の設計思想 に由来
- 当時は ディスクI/O が最大のボトルネック
- 現代は RAM搭載量の増加、 NVMeなどの高速ストレージ、 CPU/メモリ帯域 の重要性上昇
Postgresクエリエンジンの仕組みと課題
- Postgresは Volcanoモデル というシンプルな実行モデルを採用
- 各ノードが next()メソッド を持ち、1行ずつ処理
- シンプルな反面、 関数呼び出しのオーバーヘッド や バッチ処理の欠如 がパフォーマンス低下の原因
クエリエンジン最適化の実践例
- 500,000,000件の合計計算クエリを例に、RustとPostgresで速度比較
- Postgres：約 20秒
- Rustのforループ： 358ms （約55倍高速）
- Volcanoモデルのミニ実装： 1.3秒
- バッチ処理 導入で 480ms まで短縮
- オペレーターフュージョン で 358ms （forループ同等）を実現
- SIMD （Single Instruction Multiple Data）最適化で 135ms、さらに高速化
最適化手法の解説
- バッチ処理
- 1回の関数呼び出しで複数行を処理
- スタック上にバッファを確保し、メモリアロケーションを最小化
- オペレーターフュージョン
- 連続する処理を1ノードにまとめ、コピーのオーバーヘッドを排除
- SIMD
- CPUのベクトル命令で複数データを同時処理
- 浮動小数点演算のため、コンパイラ自動化が難しいが手動で実装
パフォーマンス比較まとめ
| 実装 | 実行時間 | Postgres比速度 | |----------------------|----------|---------------| | Postgres | 20秒 | 1× | | Volcanoモデル | 1.3秒 | 15.4× | | + バッチ処理 | 480ms | 41.7× | | + オペレーターフュージョン | 358ms | 55.9× | | + SIMD | 135ms | 148.1× |
- 3つのシンプルな最適化で 10倍以上の高速化 を実現
- これらの最適化が、pgrustの分析系クエリでPostgresを圧倒的に上回る理由
ベンチマーク環境
- AWS c8g.4xlarge（Graviton4, 16 vCPU） を使用
- PostgreSQL 18.4、
max_parallel_workers_per_gather = 0 - データは共有バッファに常駐
- Rustは
cargo build --releaseでビルド、1プロセス・1マシンで計測
pgrustプロジェクトの今後
- JITコンパイル によるさらなる最適化の可能性
- 詳細は今後のアップデートで解説予定
pgrustを応援する方法
- GitHubスター でプロジェクト支援
- 最新情報は以下で配信
- GitHub
- Discord
- メーリングリスト（週次アップデート）
- pgrust.com
pgrust は、現代ハードウェアに最適化された新世代のデータベースエンジン。 今後の進化にも注目。
ここに作者がいます。投稿やpgrustについて質問があれば教えてください。みんなが一番気になるであろう質問に答えてみますね：pgrustをどう信頼すればいいの？今の私たちの最優先事項は正確性です。この2週間、形式的検証と差分ファズテストを組み合わせて行ってきました。pgrustとPostgresの両方で、1000以上のユーザー向け関数が全く同じロジックであることを証明できました（興味があれば証明ディレクトリを見てみてください）。形式的検証が難しいケースでは、関数のC実装とRust実装を使って、何百万もの入力をそれぞれに通して、毎回同じ結果が得られることを確認しました。まだ表面的な部分の約15%しかカバーしていませんが、その過程でpgrustで約100のバグ、Postgres自体で約20のバグを発見しました。私が見つけたPostgresのバグの中で一番好きなのはこれです[0]。Postgresにはクワッドツリーの実装があります。浮動小数点の丸めの影響で、ある点がクワッドツリーの中心点の上でも下でもない、さらには同じでもないということが可能でした。また、Antithesis[1]と提携してJepsenスタイルの障害テストを行い、Aretta[2]と一緒により本格的な形式的検証を進めています。プロジェクトをサポートしたい場合は、GitHub[3]でスターを付けてくれると嬉しいです。