問題タブ [query-planner]

これは私たちを当惑させました...

CAST を使用して float を decimal に変換するクエリがあります。このクエリは、多数のテーブルを結合して、返される行を見つけます。テーブルの 1 つの行の 1 つに、10 進数への CAST で算術オーバーフロー エラーが発生する値が含まれています。

奇妙なことに、この値を持つ行は、結果セットで返される行の 1 つではありません。

非常に単純化された例:

クエリ:

... 算術エラー

WHERE 句でその行を明示的に除外すると、エラーはなくなります。例えば。WHERE ... AND ID <> 3

.. 正常に動作します

これがどのように可能か知っている人はいますか？

注: ここでの問題は、CAST が ID 3 の行で失敗することではありません! 問題は、WHERE 句が ID 3 の行を除外しているにもかかわらず、クエリが失敗することです。値が 11111.1 の行が WHERE 句によって返されない場合、クエリはどのように失敗するのでしょうか?

テーブルとインデックスのテスト (PostgreSQL 12.1):

最初のクエリでは、すべて問題なく、適切なインデックス "ind" が使用されます。

' ::text ' 型キャストの'2020-02-08' (既にテキスト) を使用すると、クエリのパフォーマンスが非常に低い理由

小規模な Postgres 10 データ ウェアハウスについて、分析クエリの改善をチェックしていたところ、改善の可能性が基本的にこのサブクエリに帰着するかなり遅いクエリを発見しました (従来のグループあたり最大 n 問題)。

次の実行計画を使用します。

行の見積もりは絶対に間違っています! 私にとって奇妙なことは、結合を今すぐ右結合に変更した場合です。

実行計画では:

行の見積もりははるかに優れています!

たとえば、並列シーケンシャル スキャンは、状況によってはパフォーマンスを低下させる可能性がありますが、行の見積もりを変更するべきではないことを認識しています!? 私が正しく覚えていれば、集計関数もインデックスの適切な使用をとにかくブロックし、追加の多変量統計 (例: tuple ) を使用しても潜在的な利益は見られませんid, load_dts。データベースはVACUUM ANALYZEd.

私にとって、クエリは論理的に同じです。

クエリ プランナーをサポートして、見積もりに関するより良い仮定を作成したり、クエリを改善したりする方法はありますか? たぶん、誰かがこの違いが存在する理由を知っていますか?

編集：以前は、参加条件ON s_postings.id::text = current_postings.id::text を変更して、ON s_postings.id = current_postings.id誰も混乱させないようにしました。この変換を削除しても、クエリ プランは変更されません。

Edit2: 以下に示すように、greatest-n-per-group問題には別の解決策があります。

非常に優れたソリューションですが、悲しいことに、クエリ プランナーも行数を過小評価しています。

SQL の使用経験から、MDX をゆっくりと学ぼうとしています。PostgreSQL などの DBMS では、たとえば を使用してクエリのクエリ プランを取得できますEXPLAIN。これは MDX のどのバージョンでも可能ですか。私はこの性質のものに出くわすことができませんでした。

分散 SQL クエリ プランナー (クエリ エンジン) を作成しています。データは、ネットワーク I/O を伴う RDBMS(PostgreSQL) ノードからフェッチされます。

JOIN クエリを最適化したい。

論理的な実行順序は次のとおりです。

1. JOINする（ON句を利用する）
2. 結合結果に WHERE 句を適用します。

Filter(テーブルに固有の WHERE 句) を最初に適用してから結合することを考えていました。どのような場合に、それが間違った結果になるのでしょうか?

例：

論理実行:

1. joinResult = (tableA left join tableB ON() ) left join tableC ON()
2. 指定された WHERE 句を使用して joinResult をフィルタリングします。

実行案:

1. filteredA = tableA WHERE tableA.colY < 100

   filteredB = tableB WHERE tableB.colX > 50

2. 結果 = (filteredA left joinfilteredB ON(..))left join tableC ON(..)

このようなクエリを最適化できますか? つまり、最初にテーブルをフィルタリングしてから、その上に結合を適用します。

編集:一部の人々は、この特定の例について混乱して話している. この特定のクエリ例について話しているのではなく、クエリプランナーを書いていて、すべてのタイプのクエリを処理したい

各テーブルはシャード化され、異なるマシンに保存されていることに注意してください。現在の実行モデルは、各テーブルをフェッチしてからローカルで結合することです。したがって、フェッチする前に WHERE フィルターを適用すると、より良い結果が得られます。