概要
- 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 は、現代ハードウェアに最適化された新世代のデータベースエンジン。 今後の進化にも注目。