問題タブ [query-planner]

プロファイル用とプロファイルの雇用状況用の 2 つのテーブルがあります。2 つのテーブルには 1 対 1 の関係があります。1 つのプロファイルに雇用状況がない場合があります。テーブル スキーマは次のとおりです (わかりやすくするために、無関係な列は削除されています)。

これらの表を使用して、すべての失業者のプロファイルをリストするように求められました。失業者プロファイルは、雇用記録を持たないプロファイル、または「承認済み」以外のステータスで雇用されているプロファイルとして定義されます。

私の最初の暫定的なクエリは次のクエリでした。

ここでの前提は、すべてのプロファイルがそれぞれの雇用とともにリストされることであり、その後、where 条件でそれらをフィルタリングできます。雇用記録のないプロファイルは、雇用状況がnullであるため、条件によってフィルタリングされます。ただし、このクエリは、雇用されていないプロファイルを返しませんでした。

いくつかの調査の後、この投稿を見つけ、それが機能しない理由を説明し、クエリを変換しました。

これは実際に機能しました。しかし、私の ORM はわずかに異なるクエリを生成し、うまくいきませんでした。

唯一の違いはselect句です。このわずかな違いがなぜこのような違いを生むのかを理解しようとしました。3 つのクエリすべてについて説明と分析を実行しました。

最初と 2 番目のクエリ プランは、一方のハッシュ結合と他方の右ハッシュ結合を除いてほとんど同じですが、最後のクエリは結合または where 条件さえ実行しません。

私はうまくいった4番目のクエリを思いつきました:

この件に関する私の質問は次のとおりです。

1. 構造は同じなのに、2 番目と 3 番目のクエリのクエリ プランが異なるのはなぜですか?
2. 同じ構造なのに、最初と 4 番目のクエリのクエリ プランが異なるのはなぜですか?
3. Postgres が 3 番目のクエリの join と where 条件を完全に無視するのはなぜですか?

編集：

次のサンプル データでは、予想されるクエリは 2 と 3 を返すはずです。

私はテーブルを持っています

each でパーティション化され、eachAでサブパーティション化されますB(つまり、それぞれ単一の値を持つパーティションをリストします)。Aカーディナリティが 10 未満であり、Bカーディナリティが 100 未満です。T約60億行あります。

クエリを実行すると

最上位のパーティション ( の場合A != 1) をプルーニングしますが、すべてのサブパーティションでテーブル スキャンを実行して、 の個別の値を見つけますB。パーティションの設計に基づいて、パーティションの制約をチェックして指定された の可能な値を決定するだけでよいことがわかると思いましたがB、A残念ながらそうではありません。

Aまたはにはインデックスはありませんが、各パーティションにB主キーがあり(C,D)ます。これは重要ではないように見えますが、言及する必要があると考えました。BRINインデックスも持っていますC。テーブル スキャンを回避するために、Postgres クエリ プランナーがサブパーティションの制約を調べない理由はありますか?

バージョン 9 シリーズからのアップグレードを試みており、10 および 11 では問題なく動作するが、12 および 13 では何倍も遅くなる、契約を破る低速のクエリがあります。11 および 12 シリーズのマイナー バージョンでテストしました。 、マイナー バージョンは影響しません。

問題は、プランナーが使用すべきハッシュ結合ではなく、ネストされたループ結合を選択することにあります。

v11 ハッシュ結合:

v12 ネストされたループ:

テスト環境でのアップグレード手順は、このクエリをテストする前に pg_upgrade と完全な分析で行われます。

12で何が変わったの？