PostgreSQL オプティマイザーの 10 年間の改善 · Ryan Marcus

2024 年 4 月 12 日

クエリ最適化の研究者として、私はこれまでの 10 年間、最も洗練されたオープンソースのクエリ オプティマイザーを試し、学び、その上に構築することに費やしてきました。 PostgreSQL。 最近、私がデータベースに取り組み始めてから 10 年間で PostgreSQL がどれほど改善されたか疑問に思いました。 変更履歴や意見記事はたくさんありましたが、強力な実証的比較が見つからなかったので、 結合順序のベンチマーク （仕事） ^{PostgreSQL 8 ～ 16 で、各データベース バージョンの 90 パーセンタイル クエリ レイテンシを記録しました。}

各バージョンをビルドしました ^{Arch Linux を備えた Docker コンテナ内で GCC 13.2 を使用して PostgreSQL を実行します。 インデックス/IO パフォーマンスではなく、クエリ オプティマイザーの品質を測定したかったため、次のように設定しました。 shared_buffers 〜 8GB (データベース全体を保持するのに十分な大きさ)。 私も設定しました work_mem すべてのバージョンで最大 8MB。 各クエリはキャッシュをウォームアップするために 1 回実行され、その後、さらに 5 回実行された場合の待機時間の中央値が記録されます。}

全体、 PostgreSQL のテールパフォーマンスが大幅に向上ただし、バージョン 13 ～ 16 はほぼ安定しています。 バージョン 8 とバージョン 16 を比較すると、 PostgreSQL のオプティマイザーは、過去 10 年間でテール レイテンシをほぼ半分に削減しました。

クエリ分布全体を調査することもできます (対数スケールに注意してください)。

回帰分析を使用すると、(1) レイテンシの下降勾配が顕著であることを確認し、(2) PostgreSQL の各バージョンによってどの程度の改善がもたらされるかを定量化できます。 PostgreSQL のメジャー バージョン番号をクエリのレイテンシーに対して回帰すると、PostgreSQL の新しいメジャー バージョンごとに平均して、 15% のパフォーマンス向上 結合順序ベンチマーク (）。 ただし、線形モデルはおそらく変化の尺度としては不十分です (）。

もちろん、これらの改善のすべてがクエリ オプティマイザーによるものではありません。 並列ワーカーからジャストインタイム (JIT) コンパイルまで、実行エンジンの改善も役割を果たします。 JOB の各クエリ プランが 1 年間でどのように変化したかを調査するのは興味深いでしょう…おそらく次回!

改善の定量化はさておき:

• データベースをアップグレードしてください! PostgreSQL 8 から 16 に移行すると、ワークロードのテール レイテンシーが大幅に改善される可能性があります。
• 研究者は、PostgreSQL が少し流動的なターゲットであることに注意する必要があります。 学習されたクエリ最適化研究では、時間をかけて PostgreSQL のさまざまなバージョンと比較されてきました (たとえば、Neo と Bao はバージョン 11 と比較されますが、新しい研究はバージョン 14、15、または 16 と比較されます)。したがって、古い技術が PostgreSQL を 30% 改善するというだけの理由で、 、新しい技術は PostgreSQL を 25% 改善するだけであるため、新しい技術はより強力な PostgreSQL と比較される可能性があります。

チェックアウトすることもできます 生データ あなた自身のための。

ノート