変更履歴
http://www.thinkit.co.jp/cert/tech/10/1/3.htm
正確に最適な共有メモリサイズを求めることもできますが、
ここでは簡単な目安として、サーバマシンの搭載メモリ量の1/4〜1/2を設定することをお勧めいたします。
通常は1/4程度でいいと思いますが、潤沢なメモリ量を搭載している高性能サーバマシンの場合には1/2という選択肢も有力です。
http://www.thinkit.co.jp/cert/marugoto/2/1/11/2.htm
ところで、「メモリが空いているようなのでそれをPostgreSQLで有効に使いたい」という質問に対して
「shared_buffersをできるだけ多く取ってください」というような回答を目にすることがよくありますが、前述のようにそれは間違いです。
PostgreSQLでは、むしろ余ったメモリをOSにバッファ領域として使ってもらった方がトータルでの性能が向上します。
http://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server/ja
1GB以上のRAMを持つシステムであれば、shared_buffersの理想的な開始値はシステムメモリの1/4です。
http://www.thinkit.co.jp/cert/marugoto/2/1/12/2.htm
たとえば1Gバイトのメモリを実装するシステムであれば、その1/2〜1/4、すなわち65536から32768程度に設定するのが妥当です。
:
effective_cache_sizeの値を大きくすると、オプティマイザがインデックスを使用した問い合わせプランを選択する傾向が強くなります。
インデックスについては、後ほど詳しく説明します。
http://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server/ja
effective_cache_sizeを全メモリの1/2に設定することが通常の保守的な設定です。
メモリの3/4はより積極的ですが、まだ合理的な値です。
オペレーティングシステムの統計情報を参照することでより良い推定を行うことができます。
Unix互換のシステムでは、推定値を得るためにfreeまたはtopコマンドのfree+cached数を加えてください。
http://www.thinkit.co.jp/cert/tech/10/5/2.htm
逆にチェックポイントの頻度が少ないと、トランザクションログにページ全体が書き出される機会が減り、
結果としてトランザクションログのサイズが小さくなります。
トランザクションログのサイズが小さくなれば、それだけハードディスクへのI/O量が減るため、性能も向上します。
:
デフォルトは3セグメントでしたから、これよりも大きくすれば性能は向上します。
ただし意外とハードディスクの容量を必要としますので、むやみに大きくすることはできません。
ハードディスクにどれくらいの余裕があるかを調べた上で、きちんと計算して決めましょう。
また大きくしすぎるとリカバリに時間がかかるようになりますから、そのことが後々問題になりそうなら控えめに設定した方がいいでしょう。
http://www.thinkit.co.jp/free/marugoto/2/1/12/1.html
チェックポイントは同期書き込みを伴う比較的負荷の高い処理であり、あまりチェックポイントが頻発するとパフォーマンスが低下します。
ディスク容量に十分余裕がある場合は、checkpoint_segmentsの値を増やしてチェックポイント頻度を低減するとよいでしょう。
http://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server/ja
非常に小規模な設定で実行していない限り、最低10に設定することで確実に改善されます。これにより通常目標の完成度を増大させます。
書き込みが激しいシステムでは32(512MBごとのチェックポイント)から256(128Gごとのチェックポイント)が最近よく使われます。
非常に大きく設定すると多くのディスクを使用することになり、データベースのリカバリの際に時間がかかるようになります。
このため、大きく設定する前にこれらに問題がないことを確認してください。
http://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server/ja
空き領域マップは回収可能な不要タプル(行)が存在するかどうかを追跡するために使用されます。
不要タプルが空き領域マップに列挙されている場合のみ、効率的な非ブロックバキューム問い合わせを行います。
結果として、定期的にバキュームを行う計画を立てない場合、かつ、多くの更新があると予想される場合、これらの値が通常大きいことを確認しなければなりません
(そしてこれらの値がデータベースに対するものではなく、データベースクラスタに対するものであることは忘れないでください)。
http://www.sraoss.co.jp/technology/postgresql/8.4/
フリースペースマップの設定が自動化されました。
設定 max_fsm_pages、max_fsm_relations は廃止されています。
http://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server/ja
行の先頭に情報を追加します。一般的は'%t:%r:%u@%d:[%p]: 'が優れていますので推奨します。
デフォルトはstderr。csvログを取得するはcsvlogにする。
複数出力する場合は、"stderr, csvlog"などとする。
log_destinationにstderr、csvlogを指定した場合はonにする
http://www.postgresql.jp/document/current/html/release-8-3.html
redirect_stderrの名前がlogging_collectorになりました。
http://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server/ja
default_statistics_targetのデフォルトを(現在の10から)100まで増やすべきだと多くの人が感じています。
http://www.sraoss.co.jp/technology/postgresql/8.4/
設定 default_statistics_target のデフォルト値が、10 から 100 に増えました。 また、最大値も 1000 から 10000 に増えました。
http://postgresql.g.hatena.ne.jp/umitanuki/20090224
work_memは重要です。これのサイズによってGroupAggがHashAggになったり、MergeJoinが HashJoinになったりします。
また、外部ソートかメモリソートかの判断にも使われます。初期値1MBが最近のサーバでは小さすぎるので、8MB〜32MBまで考えてみましょう。
実際にどのぐらいメモリを使うかはプラン実行時に決まるので、32MB×100connectionだからといって必ず3.2GB使うわけではないです。
http://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server/ja
これを50MBに設定し、30ユーザが問い合わせを実行すると、実メモリとして1.5GB使用することになります。
さらに、8テーブルのマージソート処理を含む問い合わせでは、work_memの8倍が必要になります。
http://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server/ja
体験に基づくものですが、256MB程度で十分な大きさです。
http://www.thinkit.co.jp/free/marugoto/2/1/12/1.html
同期書き込みの方法はプラットフォームによっていくつか選択肢があり、一概にどれが最適とはいえないため、実際にベンチマークを計測して最適なものを選ぶとよいでしょう。
http://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server/ja
サポートしているプラットフォームであればデフォルトからopen_syncへの変更、そうでなければデフォルトからfsync系の方法の1つに変更することが一般的です。
http://www.thinkit.co.jp/cert/tech/10/2/3.htm
トランザクションログバッファの大きさは、頻繁に溢れることがない程度に大きくすべきです。
何も考えずに16ページとか32ページとかに増やしても十分良い結果がでると思います。
仮に32ページとしても必要なメモリサイズは256Kバイトでしかありませんから、サーバマシンの搭載メモリ量を気にする必要もないでしょう。
もちろん更新の非常に多い環境であれば、100ページ以上の大きな値にすることも考えられます。
http://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server/ja
wal_buffersを数キロバイトの小さなデフォルトより増加させることは書き込みが激しいシステムで役に立ちます。ベンチマークでは通常、大規模なシステムであっても1MBまで増やすだけで十分であると提案します。
http://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server/ja
二相コミットを使用しない場合(もしこれが何か知らなければ使用しません)、この値をゼロに設定することができます。
これにより共有メモリの使用量が多少節約されます。
http://postgresql.g.hatena.ne.jp/umitanuki/20090224
意外に知られていなくて効力が大きいのがこれ。
インデックスを使うかどうかの判断時にプランナがランダムアクセスのコストの単位として使うわけですが、
ディスクキャッシュが効いた状態では4というのは大きすぎるので、1～2ぐらいにしておきましょう。
これを放っておくとインデックスが正しく使われないなどの状況が生まれます。
http://www.thinkit.co.jp/cert/marugoto/2/1/12/2.htm
メモリを1〜2Gバイト搭載したマシンでは、テーブルが1000万件以上あるようなケースを除くと、デフォルトの4という数字は大きすぎるようです。
2または3程度にするのがよいでしょう（1以下にするのは不適切です）。
:
random_page_costの値を小さく設定すると、オプティマイザがインデックスを使用した問い合わせプランを選択する傾向が強くなります。
http://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server/ja
しかし、これは計画に関する問題解決を始めるところではありません。
random_page_costがこのリストのかなり下（実際一番最後）にあることに注目してください。
悪い計画になったとしても、またこの値を小さくして効果があったとしても、これは検討する最初の項目ではありません。
代わりに自動バキュームが適切に動作しているかどうかを確認することから始めてください。
そして十分な統計情報を収集しているか、サーバのメモリに関するパラメータを正しく割り当てているかを確認してください。
これはすべてこれまで説明してきたことです。これらのより重要な事柄を行っても、悪い計画となり続けるのであれば、random_page_costを小さくしたら有用かどうかを確認してください。
http://www.thinkit.co.jp/cert/marugoto/2/1/11/2.htm
この問題を回避するには、deadlock_timeoutを長めに設定します。デフォルトは1000ミリ秒（すなわち1秒）ですが、これに同時セッション数を乗じた値にするとよいでしょう。
たとえば同時セッション数が100ならば100000にします。
http://itpro.nikkeibp.co.jp/members/ITPro/oss/20050722/165140/?P=2
メモリーが充分に搭載されており，一時テーブルを使って大量のデータ処理を行うような用途では，temp_buffersを大きくすることによって処理性能の向上が期待できる。
http://www.thinkit.co.jp/cert/marugoto/2/1/12/2.htm
commit_delayを0以外にすると、コミットしてから指定された時間だけ待って同期書き込みを行うようになります。
同期書き込みを待っている間にほかのトランザクションがコミットすれば、同期書き込みがまとめて行えるため、書き込みの効率が向上します。
http://d.hatena.ne.jp/nekoruri/20090226/
HOTを利用するにはFILLFACTORパラメータをテーブル作成時に指定する必要があります。デフォルトでは100%になっているためHOTが機能しません。
また、HOTの原理上インデックスが張られているカラムを更新した場合は効果が出ないため、可能ならばそれを前提にインデックスを設計するのが良いでしょう。
HOTに限らず、PostgreSQLの特性を設計で考慮すべき、というのは一般論でもあります。