PostgreSQLを遅くしている犯人はどこだ？
これにより、3秒以上の時間がかかるSQLをキャプチャすることができます。 ただし、もし実行されたSQLのほとんどでこの設定値以上の時間がかかる場合、ログへの出力自身がオーバヘッドとなり、かえって性能劣化の引き金となる可能性がありますので、値の設定には配慮が必要です。通常運用中は、10sや20sといった、正常状態ではたどり着かない程度の値を設定しておくことをお勧めします。 今回、このパラメータを設定したうえでアプリケーションを実行させると、以下のような出力結果を得ることができました。 LOG: duration: 9094.865 ms statement: SELECT c_fname, c_lname, c_phone, c_email, o_id, o_date, o_sub_total, o_tax, o_total, o_status, cx_type, cx_auth_id FR
postgresql パフォーマンスチューニング
このサイトは、もともと作者の自分用メモとして書き始めたものです。書いてあることが全て正しいとは限りません。他の文献、オフィシャルなサイトも確認して、自己責任にて利用してください。 数十万レコードのデータを持つ大規模なテーブルを扱うようになると、クエリによっては回答が得られるまでに数秒かかるケースも出てくる。これは、より多くのメモリやディスクの使用を PostgreSQL に許すことで改善される可能性が高い。ただし、扱っているデータベースが小さい時には大した効果は望めない。また、そもそもの実装メモリが 256M とか 128M という貧弱な状態では、調整の余地さえなく、単なる悪あがきだ。以下は搭載メモリ 1 ギガを目安に書いている。更に、テーブルの素性とクエリパターンによっては、テーブル自体のクラスタ化が加速を上乗せしてくれるかもしれない -- クラスタリングや適切なインデックスの作成は、メ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
log_min_duration_statement
