多くのテーブルを結合するいくつかのクエリでデータベースが突然ハングし、次のように表示されます。
temporary file size exceeds temp_file_limit (1025563kB)
サンプルクエリとクエリプランは次のとおりです。
http://www.sharecsv.com/s/a6333a7f610e049dd81ebcfc19a4c02f/temp_file_limit_exceeded.csv
通常、このクエリの所要時間は100ミリ秒未満ですが、一時ファイルのサイズ制限に達するとハングします。
私が走ると:
SELECT temp_files AS "Temporary files", temp_bytes AS "Size of temporary files"
FROM pg_stat_database db;
そうですか:
Temporary files Size of temporary files
---
22550 10651900248
どうすれば解決できますか?
私は問題の多くを有効にすることができました。ユーザーが2つの言語を話すことができるとリストしているとします-クエリは正常に実行されます。次に、プロフィールを編集して、20の言語を知っていると言います。クエリはtemp_file_limit
とぶら下げ。
約200の列を取得するために約40のテーブルを結合しています。私は掘り下げませんでしたが、通常、そのようなクエリは誤解です。どちらの方法でも、一時ファイルのlotを蓄積するのは当然です。
また、同じセッションのall一時ファイルは制限に対してカウントされることに注意してください。バインドされたカーソルはそのように問題になる可能性があります。または、同じトランザクション内の複数の大きなクエリ。
デフォルトでは、パラメータ temp_file_limit
は-1に設定されています。これは、「制限なし」を意味します。したがって、クエリをサニタイズするか、制限を削除または拡張してください。 (スーパーユーザーだけがそれを行うことができます。)
どちらも変更できない場合は、work_mem
をさらに設定すると、RAMでより多くの操作を維持できるため、必要な一時スペースが少なくなります。
この設定をtemp_buffers
と混同しないでください。これはほとんど関係がなく、一時オブジェクトに使用できるRAMの量を設定します(CREATE TEMP TABLE
のように... )
そして、あなたはあなたのPostgresのバージョンについて言及することを気にしませんでした。たぶん時代遅れ?
統計が古くなって、同じクエリプランがさらに悪いクエリプランで実行される可能性がありますか?