postgres 12でのjitのパフォーマンス問題の処理
tl; dr：jitによるパフォーマンスの低下を処理する最良の方法は何ですか？
背景：
最近、私はpostgres 11から12に移行し、いくつかのクエリ/プロシージャの実行がかなり遅くなっていることに気付きました。私はいくつかの調査を行い、さまざまな構成をテストしました-結局、jitのオーバーヘッドはその利益を上回っています。次の2つの解決策が考えられます。
set jit = off;を1回実行して、すべてのクエリに対してjitを永久に無効にします。これは役立ちますが、自然な感じではありません。 （おそらく、デフォルトの構成を変更したためです。そのような必要はなかったので、私はあまりしませんでした。デフォルトは正気であり、それらを変更する必要がある可能性は低いです。）これは、長いクエリを実行するときに、可能なパフォーマンスの向上を捨てることも意味します。 。手順の最初でjitを無効にし、最後で有効にします。並行して実行されるクエリの構成を変更した場合の影響については異論があります。もちろん、これは並行して実行されるログクエリのパフォーマンスに悪影響を与える可能性があります。また、これは最初のソリューションよりも適切ではないようです-手順の一部として構成を変更します。
これを処理する最良の方法は、設定を微調整することです。これにより、jit全体が破棄されず、実行時に設定が変更されません。残念ながら、私はそれがどのようにして可能になるのかについてほとんどまたはまったくリソースを見つけられませんでした（ documentation のjit_above_costのようなパラメータのみはほとんど役に立たないようです）。
質問：この問題を解決する最良の方法は何ですか？実行と測定を除いて、いつjitを無効にするかに関する基準はありますか？動作を微調整できますか（たとえば、特定のクエリに対してjitを無効にします）？
私の意見では、v12でデフォルトのjitを 'on'に変更するのは誤りでした。その時点でもっと注意を払っていたら、変更に反対したでしょう（もちろん、私が勝ったという意味ではありません）。変更は、少なくともそれが役立つのと同じくらい多くの人々に害を及ぼすようです。そして、この機能を楽しみにしていた人々は、きっとデフォルトを変更することに頼ることができるでしょう。
デフォルトは正気であり、それらを変更する必要がある可能性は低い
私はあなたがデフォルト全般を尊重しすぎていると思います。それらは基本的に信頼できる最小のマシンサイズに設定されています。一般的に適切に選択された設定でさえ、適切に選択されない場合があります。
これは、長いクエリを実行するときに、可能なパフォーマンスの向上を捨てることも意味します。
そのようなクエリの例はありますか？一般に、クエリはjitが意味をなすほど実行時間が長いため、CPUにバインドされなくなった十分なデータに触れ始めるため、jitを使用するかどうかは比較的重要ではありません（または、インデックスがないため、の修正はjitよりもはるかに重要です）。もちろん、これは普遍的に当てはまるわけではなく、例があれば、それを使用してjit_above_costの設定をターゲットにすることができます。 （jit_above *の問題の1つは、総コストの見積もりに基づいていることです。これは一般にIOのコスト見積もりに支配されます。しかし、見積もりIOに基づいてJITを使用するかどうかを選択するコストは意味がありませんが、これらのタイプのコスト見積もりを分離するためのインフラストラクチャが整っていません。