問題タブ [query-planner]

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

0 投票する
1 に答える
3575 参照

postgresql - pl/pgsql を使用したクエリ プランのキャッシュ

pl/pgsql でクエリ プランのキャッシュがどのように機能するか理解できません。

JOINs とs を使用してオールインワン クエリを作成したいIFので、複数の異なるクエリ パラメータを使用し、複数のテーブルを検索します。

最初は、pl/pgsql を使用すると、パラメーターの組み合わせごとに異なる計画が生成されると考えていましたが、そうではありません。複数のテーブルがあるためです。

PL/pgSQL 関数に直接現れる SQL コマンドは、実行のたびに同じテーブルと列を参照する必要があります。つまり、SQL コマンドでパラメーターをテーブルまたは列の名前として使用することはできません。この制限を回避するために、PL/pgSQL EXECUTE ステートメントを使用して動的コマンドを作成できますが、新しい解析分析を実行し、実行ごとに新しい実行計画を作成するという代償を払います。 ここから

毎回新しい分析を実行すると、物事が遅くなる可能性があると思います。使用しないEXECUTE場合

ステートメントにパラメーターがない場合、または何度も実行される場合、SPI マネージャーは、特定のパラメーター値に依存しない汎用プランを作成し、それをキャッシュして再利用することを検討します。通常、これは、実行計画がその中で参照される PL/pgSQL 変数の値にあまり敏感でない場合にのみ発生します。もしそうなら、毎回計画を生成することは純利益です。ここから

その場合、一般的なプランを使用する必要がありますか? 毎回計画がないので速いですか、それとも遅いですか?少なくともそれらはキャッシュされます。私のクエリは動的であるため、変数に敏感ですが、

もしそうなら、毎回計画を生成することは純利益です。

実際に意味?EXECUTE毎回 /planを使用することは、一般的なものよりも良いですか、それとも悪いですか? 「ネットウィン」は私を混乱させます。

一般的な計画が不正確で、EXECUTE/planning が毎回遅くなる場合、わざわざ pl/pgsql を使用する必要はありません。次に、いくつかの if を使用して簡単なクエリを作成できます。

要するに、速度とプラン キャッシングの点でEXECUTE/plan each timeが優れているか劣っているかについては、結論を出すことはできません。generic cached plan説明とアドバイスをお願いします、私は混乱しています。

参考までに、これは私が作成しているものです。mytablesそのまま動作しますが、およびの IF がさらに追加されます。mywhere

ありがとう

0 投票する
1 に答える
227 参照

postgresql - パラメータとして関数に渡されたときに now() はどのように評価されますか

タイムゾーン フィールドを使用してタイムスタンプで範囲分割されたテーブルがあります。次の where 条件により、プランナーがパーティション内のすべての「子」テーブルをクエリするようになったことに非常に驚きました。

私が学んだように、プランナーは実行時に now() がどうなるかを知らないため、すべての子テーブルを照会するプランを生成します。それは理解できますが、そもそもパーティションを設定する目的に反します! reading_time > '2018-03-31' を発行すると、これらの条件を満たすデータを含むテーブルのインデックス スキャンのみが実行されます。

次の関数を作成するとどうなりますか

次に、関数を呼び出すことができます

now() はいつ評価されますか? 言い換えれば、リテラル時間値 (例: 2018-03-31 1:01:01+5) が関数に渡されますか? それがリテラル値の場合、Postgres は適切な子テーブルのみをクエリしますよね? しかし、関数内で now() を評価している場合は、すべての子テーブルのインデックスをスキャンする計画に戻ります。プランナーが関数内で何をしているのかを確認するのは簡単ではないようです。あれは正しいですか?