私のアプリケーションには、テーブルに多数の行がある場合に非常に高速に実行されるクエリがあります。しかし、行の数が中程度のサイズ（大小もありません）の場合、同じクエリは15倍も遅く実行されます。enable_nestloopをOFFに設定する際の落とし穴は何ですか
説明プランは、中間サイズのデータ・セットの照会が、その結合アルゴリズムのためにネストされたループを使用していることを示しています。大きなデータセットでは、ハッシュ結合が使用されます。
データベースレベル（postgresql.conf）またはセッション（SET enable_nestloop TO off）のいずれかでネストループを使用しないようにクエリプランナーを奨励できます。
潜在的な落とし穴はset enable_nestloop to offですか？
その他の情報：Windowsで動作するPostgreSQL 8.2.6。
enable_nestloop〜offの潜在的な落とし穴は何ですか？
これは、インデックスを効率的に使用できないことを意味します。
これは今使用していないようです。
このようなクエリ：
SELECT u.name, p.name
FROM users u
JOIN profiles p ON p.id = u.profile_id
WHERE u.id = :id
はおそらくuser.id上とprofile.id上でNESTED LOOPSを使用しますが、あなたはこれらのフィールドにインデックスを構築していることを条件とします。
選択性の低いフィルタ（つまり、使用するテーブルのデータが10%以上必要なクエリ）は、MERGE JOINSとHASH JOINSの恩恵を受けます。
しかし、上記のようなクエリでは、効率的に実行するにはNESTED LOOPSが必要です。
ここでクエリとテーブルの定義を投稿すると、インデックスとクエリのパフォーマンスについて多くのことが行われる可能性があります。
、このような抜本的な対策を取る前に考慮すべきいくつかのこと：
。 8.3（8.3.6）の次の安定版にアップグレードすることをお勧めします。
生産プラットフォームをWindows以外のものに変更することを検討してください。 PostgreSQLのWindowsポートは、開発目的には非常に便利ですが、まだUn * xのものと同じレベルではありません。
"Planner Method Configuration"の最初の段落を読んでください。このwiki pageもおそらく助けになります。
私はまったく同じ経験をしています。大規模なデータベースのクエリの中には、ネストされたループを使用して実行されたものがあり、それには12時間かかりました。ネストされたループをオフにするかインデックスを削除するときに30秒後に実行されます。
はヒントを持つことは、ここで本当にいいだろうが、私はこの問題に対処するために
...
SET ENABLE_NESTLOOP TO FALSE;
... critical query
SET ENABLE_NESTLOOP TO TRUE;
...
を試してみました。だから確実にネストされたループの使用を無効にして再び有効にすることができ、9000倍の速度向上を主張することはできません：
PNGSQL/PLプロシージャでENABLE_NESTLOOPを変更することが1つあります。私はAqua Data StudioですべてのことをやっているSQLスクリプトを実行できますが、PgSQL/PLプロシージャに入れると12時間かかります。どうやらそれは変更を無視していた。