postgresql パフォーマンスチューニング
このサイトは、もともと作者の自分用メモとして書き始めたものです。書いてあることが全て正しいとは限りません。他の文献、オフィシャルなサイトも確認して、自己責任にて利用してください。 数十万レコードのデータを持つ大規模なテーブルを扱うようになると、クエリによっては回答が得られるまでに数秒かかるケースも出てくる。これは、より多くのメモリやディスクの使用を PostgreSQL に許すことで改善される可能性が高い。ただし、扱っているデータベースが小さい時には大した効果は望めない。また、そもそもの実装メモリが 256M とか 128M という貧弱な状態では、調整の余地さえなく、単なる悪あがきだ。以下は搭載メモリ 1 ギガを目安に書いている。更に、テーブルの素性とクエリパターンによっては、テーブル自体のクラスタ化が加速を上乗せしてくれるかもしれない -- クラスタリングや適切なインデックスの作成は、メ
カーネルリソースの管理
17.4. カーネルリソースの管理大規模なPostgreSQLインストレーションでは、すぐに各種オペレーティングシステムのリソース制限を超えてしまうことがあります （システムによっては、実際に"大規模"なインストレーションでなくても、出荷時のデフォルトでは低過ぎるものもあります）。 この種の問題が発生したら、これらを読んでください。 17.4.1. 共有メモリとセマフォ共有メモリとセマフォはひとまとめに"System V IPC"と呼ばれます。 （メッセージキューも一緒ですが、これはPostgreSQLとは関係ありません）。 ほとんど全ての最近のオペレーティングシステムはこれらの機能を提供していますが、これらの全て、特にBSD由来で有効にされているとは限りませんし、デフォルトで十分なサイズがあるとも限りません （Windows版では、PostgreSQLは独自の代替的な実装でこれらの機能を
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
