Postgresが分析クエリで爆速化！300倍のパフォーマンスを引き出すバッチ処理・演算子フュージョン・SIMD活用術

PostgreSQLを分析用途で使う際、パフォーマンス不足に悩んでいませんか？この記事では、バッチ処理、演算子フュージョン（Operator Fusion）、そしてSIMDといった高度な最適化テクニックを駆使し、分析クエリの実行速度を最大300倍まで引き上げるための革新的な手法を解説します。大規模データを扱うエンジニア必見のパフォーマンスチューニングガイドです。

開発者本人です。投稿やpgrustについて何か質問があれば気軽にどうぞ。

一番よく聞かれそうな質問に先回りして答えてみますね。「pgrustをどう信頼すればいいのか？」という点について。現時点で最大の優先事項は正確性です。この2週間、形式検証と差分ファジングテストを組み合わせて進めてきました。1000以上のユーザー向け関数について、pgrustとpostgresでロジックが完全に一致することを証明できました（興味があればproofsディレクトリを見てください）。形式検証が難しいケースでは、C言語での実装とRustでの実装の両方に数百万通りの入力を流し込み、毎回同じ結果になることを確認しています。

まだ表面の15%ほどしかカバーできていませんが、この過程でpgrustのバグを約100個、Postgres自体のバグも約20個発見しました。特にお気に入りのPostgresのバグはこれ[0]です。Postgresにはクアッドツリーの実装があるのですが、浮動小数点の丸めのせいで、点がクアッドツリーの中心点に対して「上でも下でも、あるいは一致もしていない」という状態になり得たんです。

また、Antithesis[1]と契約してJepsenスタイルの障害テストを行ったり、Aretta[2]と協力してより本格的な形式検証を進めたりもしています。

もしプロジェクトを応援してくれるなら、GitHub[3]でスターをいただけると一番嬉しいです。

[0] https://www.postgresql.org/message-id/19597-39c532e61d78dff6%40postgresql.org
[1] https://antithesis.com/
[2] https://aretta.ai/
[3] https://github.com/malisper/pgrust

I/Oスケジューラ（ScyllaDBの新しいI/Oスケジューラのようなもの: https://www.scylladb.com/2021/04/06/scyllas-new-io-scheduler/ ）や、スレッドスケジューラの詳細なアーキテクチャ概要を知りたいな。

PostgreSQLは歴史的に「ノイジーネイバー（うるさい隣人）」問題の管理が苦手だったけど、スレッドプールやI/O優先順位があれば解決できるはず。

このプロジェクトでは、その辺りどうなってるの？

アダプティブプランニング（適応型計画）をどれだけ待ちわびていたか。Postgresのコアチームに対する最大の不満の一つが、これだけ確立された技術であり、すでに複数の商用データベースで実装されているにもかかわらず、実装に消極的だったことなんだ。せめてこれが、学術的・ニッチな文脈以外でもこのモデルが有効であることを証明してくれればいいんだけど。

面白いプロジェクトだけど……現実として、5〜10年経ってもみんなpgrustよりPostgresを選ぶと思う。技術的に優れていて速いからといって、信頼できるPostgresチームによって作られたものではないという点がネックになる。信頼というのは、開発速度やパフォーマンスよりもはるかに重要な要素だからね。重要なテクノロジーにおいて、寿命や継続性は何物にも代えがたい。

AIならもっと分かりやすい見出しが書けたはずだね。何十年も本番環境で運用し、充実したサポート、書籍、コンサルタント、マネージドホスティングといったエコシステムを活用しているユーザーからすれば、公式リリースと部分的に互換性のある書き直し版とでは、大きな違いがある。

300倍高速というのは素敵だけど、俺がクリックしたのは「オペレーターフュージョン」によって、GROUP BYがいまだに手作業で処理しているような感覚の原因が解明されるのか、それを確認したかったからだ。

質問。純粋なRustで書かれていることで、pgrustをバイナリに直接埋め込んで、SQLiteやTursoの代替として使える可能性はある？

一つ裏技があるよ。ramfsかtmpfsを作って、そこでPostgresを起動するんだ。

全部載るだけの十分なメモリがあるサーバが必要だけどね。

これ、データベースが爆速になるよ。

バッチモード実行はMicrosoft SQL Serverですでにしばらく前から実装されていて、最近AVX-512のサポートも追加されたんだよね。

空間SQLクエリをC#のカスタムベクトル化バッチモードコードに置き換える実験をしてみたんだけど、スピードアップが驚異的だった。

こういう主張を怪しむ人は、今のコンピュータが実際にどれだけの性能を出せるのか分かっていないんだと思う。

これらの最適化の一部を、Postgres側にバックポートすることはできないの？