PostgreSQLのトラブルシュートとチューニング | Let's POSTGRES
NTT オープンソースソフトウェアセンタ 笠原 辰仁 この記事は、gihyo.jp & Let's Postgres 連動企画「今こそ！PostgreSQL」の第6回記事です。第6回目は、PostgreSQLのエラーメッセージや内部情報を見て、発生している問題の特定とその対策となるチューニングを紹介します。なお、トラブルの発生・予兆を適切に捕捉するためにも、ログの設定や稼動統計情報の監視をしておきましょう。 エラーメッセージについて トラブルと対策の前にエラーメッセージのレベルについて説明しておきます。PostgreSQLは複数のエラーレベルを影響範囲や深刻度によって使い分けています。エラーレベルそれぞれの解釈の仕方を下記の表にまとめてみました。 データベース管理者は、深刻な状況である PANIC と、性能情報を含む LOG レベルのメッセージに注意しましょう。一方、アプリケーション開発者
20090107 Postgre Sqlチューニング（Sql編）
3. 実行計画とは？ 実行計画は、PostgreSQLのオプティマイザが最適だと判断したクエリを実行する個々のステップを示したもの。 Explainを使用することで、参照可能 testdb=# explain select count(id) from master where valid = true; QUERY PLAN ---------------------------------------------------------------------------- Aggregate (cost=217107.05..217107.06 rows=1 width=0) -> Seq Scan on master (cost=0.00..213742.88 rows=1345668 width=0) Filter: valid 4. ExplainとExplain analyz
VACUUM FULLとREINDEXとファイルサイズ — NPO法人 日本PostgreSQLユーザ会
by 柴田 淳 — posted at 2006-02-22 08:03 last modified 2006-12-04 12:41 「アレどうなったんですか？」といろんな人にツッコミを受け続けて早2ヶ月（くらい？）。帰ってきた「水曜日シリーズ」です。 記念すべき復帰第一弾は「VACUUMとREINDEX」です（第一弾だけで終わりませんように・・・）。 ファイルサイズは、データベースのパフォーマンスに大きな影響を与えます。ファイルのサイズを可能な限り抑えることが、パフォーマンスの向上に役立ちます。そこで今回は、VACUUMとファイルサイズ、そしてREINDEXとの関係を見ていきたいと思います。 まず、pgbenchで最初にデータを作成してみます（いきなりですが）。 % pgbench -i pgbench creating tables... 10000 tuples don
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
［PostgreSQLウォッチ］第26回 ボトルネックをビジュアルに分析するログ解析ツールpgFouine
