pgrustの新クエリエンジン「Gravity」、ClickHouseを最大3倍上回る速度を達成
Programming at Light Speed: Building the Gravity Query Engine

pgrust v0.4-betaに搭載された新クエリエンジンGravityは、ClickHouseが自ら設計したベンチマークClickBenchで最大3倍高速でありながら、PostgresのSQL方言と型システムを完全にサポートする。開発チームは既存エンジンの漸進的な高速化ではなく、ハードウェアとファイル形式の物理的限界から逆算する「光速プログラミング」を採用。Claudeに列指向ストレージクレート直接操作の最適化Rustコードを書かせて到達可能な上限を測り、その知見をSQLからアセンブリへ段階的に変換する多段コンパイラパイプラインに注入した。
エンジニアがソフトウェアを高速化するときは通常ボトムアップで進める。ベンチマークを実行し、フレームグラフを見てホットスポットを見つけ、コードを15%か20%速くする方法を考える。ボトムアップの問題は、天井がどこにあるか分からないことだ。ハードウェアが実行できる最速コードまで20%の地点にいるのか、100倍離れているのか、分からないのである。
- landhar
> 通常、エンジニアがソフトウェアを高速化しようとするとき、彼らはボトムアップで取り組みます。ベンチマークを実行し、フレームグラフを見て、ホットスポットを見つけ、コードを15%か20%高速化する方法を考えます。ボトムアップのアプローチの問題は、天井がどこにあるかわからないことです。ハードウェアが実行できる最速のコードまで20%の距離かもしれないし、100倍の距離かもしれない。
> Gravityの構築を始めたとき、私たちはこの問いを逆にしました。データベースは実際どれくらい速くなれるのか?と自問したのです。既存のクエリエンジンを段階的に高速化するのではなく、ハードウェアとファイルフォーマットの物理的な速度限界から始めて逆算したかったのです。私はこれを「光速でのプログラミング」と呼んでいます。
コードを最適化する「通常の」アプローチとして説明されているものは、実際にはもっと「素朴な」アプローチです。真剣なパフォーマンス最適化の仕事なら、まずハードウェアが許す天井を定義し、それに対してベンチマークするというアプローチを取るでしょう。そしてそれはLLM以前からすでに真実でした。
例えばこちらを参照してください: https://www.marginalia.nu/log/a_106_native_calls/
細かいことを言って申し訳ありませんが、このアプローチの一部が目新しいものではないという文脈を他の読者に提供するのは有用かもしれないと感じました。彼らがClaudeを使って最適化されたベンチマークを生成しているのはすでに十分興味深いので、記事の中でこの部分に特に注意を喚起する必要はないと感じています。
- cube2222
最近ニュースになったClickBenchに関するやや意気消沈する話の後だけに、このブログ記事はとてもクールだと言わざるを得ません。
Claudeでこの問題を解決するための素晴らしい構造化方法を見つけたようですね(記事をクリックしない人のために言うと、各クエリに対して手書き/Claude最適化のRustコードを書き、そのアセンブリを確認し、自分たちのオプティマイザが同じアセンブリに近いものを生成できるようにしようというものです)。そして記事もとても興味深く読みやすいです!
お見事、このようなブログ記事がもっと出てくるのを楽しみにしています。
- agumonkey
pgrustの人たちは歴史的にLisperなのか?