1。
私が読んだものから、それはクエリをハッシュしてDBに保持し、テキストをFSに保存します。したがって、次の懸念は、過負荷の共有メモリよりも予想されます：
テキストのハッシュはテキストよりもはるかに小さいので、長いクエリと比較して拡張メモリの消費について心配する必要はないと思います。特に、拡張機能がクエリアナライザーを使用していることを知っています（これはすべてで機能します クエリとにかく ）：
pg_stat_statements.maxの設定 10倍大きいと、10倍多くの共有メモリが必要になると思います。成長は線形である必要があります 。 ドキュメントにはそのようには記載されていません 、しかし論理的にはそうあるべきです。
他の構成値やハードウェアに関するデータがないため、設定を個別の値に設定しても安全かどうかはわかりません。ただし、成長は直線的である必要があるため、次の回答を検討してください。「5Kに設定し、クエリランタイムがほとんど成長しなかった場合、50Kに設定すると、10倍もほとんど長くなりません」。ところで、私の質問-50000の遅いステートメントを掘るのは誰ですか？ :)
2。
この拡張機能は、「価値のない」ステートメントの事前集計をすでに行っています。 DBで直接選択できるため、データを他のデータベースに移動してそこで選択すると、元のDBをアンロードして別のDBをロードするという利点しか得られません。つまり、元のクエリで50 MB節約できますが、別のクエリでも同じように使用できます。それは意味がありますか？私にとっては-はい。これは私が自分でしていることです。ただし、ステートメントの実行プランも保存します（これはpg_stat_statements拡張機能の一部ではありません）。それはあなたが持っているものとあなたが持っているものに依存すると私は信じています。クエリが多いという理由だけで、その必要はありません。繰り返しますが、拡張子が大きくなるほど大きなファイルがない限り