Postgres 16 クエリプランナーの新機能

PostgreSQL 16 クエリプランナーの新機能

• PostgreSQL 16 はクエリプランナーに多くの改善を導入し、多くの SQL クエリが以前のバージョンより高速に実行されるようになった。
• PG16 のリリースノートでこれらのプランナー改善を確認できるが、PostgreSQL の各リリースには変更点が多く、各変更について詳しい説明を提供するのは難しい。
• このブログ記事では、PostgreSQL 16 クエリプランナーで行われた 10 の改善点を掘り下げて分析し、PG15 と PG16 のプランナー出力の比較とともに、何が変わったのかを示す例を提供している。

PostgreSQL 16 クエリプランナーの 10 の改善点

• 増分ソート: PostgreSQL 13 で初めて導入された増分ソートは、結果セットの一部がすでに 1 つ以上の先行列でソートされている場合にそれを活用し、残りの列に対してのみソートを行う。
• ソート済みデータを使う集約: PostgreSQL 16 のクエリプランナーは、集約ノードに対して行をソート済みの順序で供給する計画を形成しようとするようになった。
• メモ化: PostgreSQL 14 で初めて導入されたメモ化計画ノードは、重複した値の参照を避けるためのキャッシュ層として機能する。
• アンチジョイン: PostgreSQL 16 では、アンチジョインを実行する際により小さなテーブルをハッシュできるようになった。
• 並列ハッシュジョイン: PostgreSQL 16 は FULL および RIGHT 結合型に対する並列ハッシュジョインをサポートする。
• ウィンドウ関数の最適化: PostgreSQL 16 は、ROWS モードを使う際に RANGE モードより高速なウィンドウ関数を使用できるようにする。
• 常に増加するウィンドウ関数の最適化: PostgreSQL 16 は、ntile()、cume_dist()、percent_rank() などのウィンドウ関数に対する最適化を拡張する。
• パーティションテーブルでの結合削除: PostgreSQL 16 は、パーティションテーブルで LEFT JOIN 削除最適化を許可する。
• DISTINCT クエリに対する Limit の利用: PostgreSQL 16 のクエリプランナーは、すべての行が同じ値を含んでいることを検出できる場合、結果の重複排除のための計画ノードを含めない。
• Merge Join に対するルール緩和: PostgreSQL 16 のクエリプランナーは、Merge Join を検討する際に行の順序が完全に一致していることではなく、少なくとも 1 つの先行列が正しくソートされているかを確認する。

GN⁺の見解

• PostgreSQL 16 のクエリプランナー改善は、データベース性能の向上に重要な役割を果たす。特に増分ソートやメモ化のような機能は、複雑なクエリをより効率的に実行できるようにしてくれる。
• これらの改善点は、PostgreSQL を使う開発者やデータベース管理者にとって非常に有用であり、特に大規模データを扱うシステムでは性能向上を実感できるだろう。
• PostgreSQL コミュニティの継続的な革新と改善への取り組みは、オープンソースデータベース技術の発展を牽引しており、これはユーザーや企業により優れたデータ管理ソリューションを提供する。

[GN⁺]

Hacker Newsの意見

• Postgres のクエリプランナーが実行途中でクエリを再計画できるとよい、という意見がある。データ分布に関する情報が不足しているために非効率なクエリ計画が立てられ、それが実行時間に大きく影響することがある。クエリが予想より遅く進んでいる場合、現在の進行状況に基づいてクエリを再計画する機能が必要だという。しかし Postgres はストリーミングクエリをサポートしているため、実行途中で計画を変更するにはかなり大きなインフラ変更が必要になる。
• クエリ可視化ツールとして explain.dalibo.com と www.pgexplain.dev を使っているユーザーがいる。両ツールとも似たような出力結果を提供する。
• クエリプランナーの改善はデータベースで重要な要素だが、主に思いどおりに動かないときに目立つ、という意見がある。最近の Postgres バージョンの JIT(Just-In-Time) コンパイラは、使用タイミングのヒューリスティクスが堅牢ではないようで、小さなデータでは遅くなることがあり、JIT を無効化したほうがよいという経験が共有されている。
• 実際のクエリで変更がどの程度の頻度で効果を発揮するのか、特に「可能なときは DISTINCT の代わりに Limit を使う」という変更が実際に適用されるケースがあるのか気になる、という意見がある。Postgres 開発者がこれに関する情報を持っているのか、という質問もある。
• アプリケーションテスト用の「厳格モード」があるとよい、という意見がある。このモードでは、クエリを改善できるインデックスがない場合にエラーを返し、CREATE INDICES FOR <sql> コマンドで必要なインデックスを作成できる。開発や対話的利用のための自動インデックス生成モードも提案されている。
• あるユーザーの友人が中小企業向けの Microsoft DBA として働いており、Postgres では本格的な作業はできないと主張しているという。Postgres にクエリプランナーがない事実に驚いたそうだが、これは誤情報である。MSSQL が Postgres より大規模な処理に向いているという主張は信頼できるのか、という質問がある。
• Postgres がヒント(hints)を実装しない理由について疑問が呈されている。
• Citus Data が発表した機能がなぜ postgresql.org ではなく別の場所から出てきたのか、それが有料機能なのか、それともオープンソースの追加機能なのか、という質問がある。
• Postgres が IS NOT DISTINCT FROM クエリを高速化するためにインデックスを使えるようになるのはいつなのか、という質問がある。
• あるコメントが通報され、flagged 扱いになっている。