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
SQLチューニング(3) ～ EXPLAINの実際 — NPO法人 日本PostgreSQLユーザ会
by 柴田 淳 — posted at 2005-11-17 00:00 last modified 2006-12-04 12:41 ちょっとテンパってしまっていて、ご無沙汰になってしまいました。一応ネタが続く限り続ける予定ですので、今後ともよろしくお願いします。 さて、EXPLAINの見方は前回軽く解説しましたが、今回は実際にEXPLAINの結果からチューニングをしてみます。 例えば、DBT1のテーブルやデータを使うとして、例えば SELECT c_fname, c_lname, c_phone, c_email, o_id, o_date, o_sub_total, o_tax, o_total, o_ship_type, o_ship_date, o_status, o_bill_addr_id, o_ship_addr_id, cx_type, cx_auth_id FR
Stray Penguin - Linux Memo (PostgreSQL-2)
ダンプ & リストアには様々な利点がある。万が一のサーバクラッシュへの備えや、マシン間でのデータベース移植にはもちろん。しかしそれだけでない。ファイルというポータブルな形にしてしまえばバックアップは簡単。さらに、PostgreSQL のバージョンアップの際には、リストア時に新しいサーバプログラムが構造を適宜変換して取り込むので、バージョンによるデータ互換性問題も、たいてい解決してくれる。日常的には当然だが、 PostgreSQL をバージョンアップする前には必ずダンプを取っておこう。 データベースのダンプ データそのものやテーブル構造をまるごとファイルに書き出すことができる。ファイルに書き出されるのは、リストアに必要なSQLコマンド。一切合切をいっぺんにダンプできる pg_dumpall を使う方法もある。 コマンド書式： pg_dump options database > ダンプ先fi
SQLチューニング(2) ～ 実行コスト(EXPLAIN / EXPLAIN ANALYZE） — NPO法人 日本PostgreSQLユーザ会
by 柴田 淳 — posted at 2005-10-26 23:48 last modified 2006-12-04 12:41 アプリケーションも何も無いのに、単に「デキの悪いSQLを作って、それをチューニングする」というのは非常に難しい。。 というわけで、とりあえず適当なサンプルデータを取ってくることにしました。ちょうど、IPAのOSS推進フォーラムでOSDLのDBT-1というベンチマークを浸かってPostgreSQLの評価をするとかの資料があったので、これをちょいと利用させてもらって、DBT-1のデータを作成することにしました。 がさごそ。がさごそ。 というわけで、ちょっと手間がかかったのですが、テーブル10コから構成されるサンプルデータベースが作成されました。もちろんサンプルデータもあります。 testdb=# \d List of relations Schema |
［PostgreSQLウォッチ］第17回 新しい実行プラン・タイプによるPostgreSQL 8.1の性能向上
前回は開発中のPostgreSQL 8.1で，バッファ・マネージャに改良が加えられて，大幅な性能向上があったことを述べた。今回は同じく性能面で大きな前進となるビットマップ・ベースの実行プラン・タイプが追加されたことを報告する。なお，本稿で検証に使用したのは5月3日時点のバージョンである。 オプティマイザと実行プラン その前に，PostgreSQLにおけるオプティマイザと実行プランについて復習しておこう。 テーブルにはアクセスを高速化するためにインデックスを追加することができる。インデックスとは日本語で「索引」のことである。例えば書籍を例にとって考えてみよう。ある書籍の中から，「神奈川県」について書かれたページを探したいとする。もし索引がなければ書籍の1ページ目から丹念に読んでいくしかない。しかし索引があれば，「神奈川県」について書かれたページがすぐに分かるので，素早く目的のページにたどり着
Ywcafe.net
Ywcafe.net This Page Is Under Construction - Coming Soon! Why am I seeing this 'Under Construction' page? Related Searches: Free Credit Report music videos Migraine Pain Relief Best Mortgage Rates Credit Card Application Trademark Free Notice Review our Privacy Policy Service Agreement Legal Notice Privacy Policy
PostgreSQLでINSERT時に振られたIDを取得 - Issei.M blog - Netsket Inc.
PostgreSQLでINSERT時に振られたIDを取得 これはどのRDBMSを使っていてもあると思いますが、 たった今直前にINSERTしたレコードの、SERIAL型のカラムに割り振られた番号などを 取得したい時ってありますよね。 SERIAL型は、MySQLで言うところのAUTO_INCREMENTですが、 MySQLの場合、PHPで処理する時は、mysql_insert_id()を使ったり、 select last_insert_id() from ...を問い合わせれば解決しますが、PostgreSQLだとそう簡単にいかない…。 実際取得する際は、目的のINSERT後に select currval('users_seq') のように、currvalに目的のカラムのシーケンス名を渡してやれば取得できるのですが、 小規模なwebシステムではイマイチスマートじゃない(と思うの
[ThinkIT] 第5回：高度なインデックスの活用 (1/2)
ここまでは単一の列に対して作成するインデックスを前提にお話ししてきました。しかし、インデックスは同一テーブルの複数の列に対してまとめて設定することもできます。検索条件に複数列を指定する場合などは、このようなインデックスを使えばさらに効率よく処理を行うことができます。
[ThinkIT] 第4回：インデックスの活用によるチューニング (1/2)
インデックス（index）は検索処理を高速化するデータ構造です（日本語で「索引」と呼ばれることもあります）。インデックスを使うと、検索処理が高速化する一方、更新処理時のオーバーヘッドが増加して、処理速度に悪影響を与えます。したがって、インデックスは作ればよいというものではありません。必要十分なインデックスを作ることが基本です。 PostgreSQLにはB-treeインデックス、ハッシュインデックス、R-treeインデックスなどがあります。R-treeインデックスは幾何データ型専用です。デフォルトで使用されるのはB-treeインデックスです。実装が一番洗練されているので、特に理由のない限りB-treeインデックスの使用をお勧めします。本稿でも以下「インデックス」と言えばB-treeインデックスを指すことにします。 B-treeインデックスを有効に利用するためには、その動作原理を理解しておくこ
無料サービスを使え！ – 役立つ無料サービスのレビュー、まとめ、比較記事を紹介
コンテンツへスキップ 無料で使える！HubSpotの顧客リストの活用法 無料のアンケート作成ツール 比較／まとめ 無料「Excel」 テンプレート 比較／まとめ 無料で使えるノートアプリ比較 (Evernote / OneNote / Google Keep) おすすめの無料Web会議システム5選 WebP Converter 徹底解説！初心者でも直ぐに使える HubSpot は、マーケティング、セールス、サービスのためのCRM（Continue reading 多くの人の声を聞くことで改善できることも多い 企業や団体など運営していContinue reading 就職・転職には必須となる履歴書・職務経歴書 これから就職活動をスタートContinue reading 便利なノートアプリで効率的な仕事をしよう いつの時代も仕事をしていてメContinue reading 近年、リモートワーク
PostgreSQLを遅くしている犯人はどこだ？
PostgreSQLを遅くしている犯人はどこだ？：Linuxトラブルシューティング探偵団（3）（1/3 ページ） NTTグループの各社で鳴らした俺たちLinuxトラブルシューティング探偵団は、各社で培ったOSS関連技術を手に、NTT OSSセンタに集められた。普段は基本的にNTTグループのみを相手に活動しているが、それだけで終わる俺たちじゃあない。引き続きOSSに関するトラブルの解決過程を＠ITで連載していくぜ。 ソースコードさえあればどんなトラブルでも解決する命知らず、不可能を可能にし、多くのバグを粉砕する、俺たちLinuxトラブルシューティング探偵団！ 助けを借りたいときは、いつでもいってくれ！ OS：高田哲生 俺はリーダー、高田哲生。Linuxの達人。俺のようにソースコードレベルでOSを理解している人間でなければ、百戦錬磨のLinuxトラブルシューティング探偵団のリーダーは務まらん。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
PostgreSQL 8.3.6文書 - 11.2. インデックスの種類
PostgreSQL 8.3.6文書
PostgreSQLの組み込み関数
PostgreSQLのTips - satospo
[ThinkIT] 第3回：VACUUMの活用によるチューニング (1/2)
PostgreSQLのインストール（Debian sarge）