タグ

関連タグで絞り込む (0)

  • 関連タグはありません

タグの絞り込みを解除

PostgreSQLとSQLとProgrammingに関するagwのブックマーク (15)

  • 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

    agw
    agw 2010/01/28
    REINDEXを行なって、インデックスも整理する話。
  • 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

    agw
    agw 2010/01/28
    EXPLAINによるパフォーマンスチューニング。兎に角分かりやすい。
  • PostgreSQL 8.3.6文書 - 11.2. インデックスの種類

    agw
    agw 2010/01/28
    PostgreSQLにおけるインデックスの作成方法。
  • Stray Penguin - Linux Memo (PostgreSQL-2)

    ダンプ & リストアには様々な利点がある。万が一のサーバクラッシュへの備えや、マシン間でのデータベース移植にはもちろん。しかしそれだけでない。ファイルというポータブルな形にしてしまえばバックアップは簡単。さらに、PostgreSQL のバージョンアップの際には、リストア時に新しいサーバプログラムが構造を適宜変換して取り込むので、バージョンによるデータ互換性問題も、たいてい解決してくれる。日常的には当然だが、 PostgreSQL をバージョンアップする前には必ずダンプを取っておこう。 データベースのダンプ データそのものやテーブル構造をまるごとファイルに書き出すことができる。ファイルに書き出されるのは、リストアに必要なSQLコマンド。一切合切をいっぺんにダンプできる pg_dumpall を使う方法もある。 コマンド書式: pg_dump options database > ダンプ先fi

    agw
    agw 2010/01/28
    リストア後にはVACUUM ANALYZE、という話。
  • 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 |

    agw
    agw 2010/01/28
    EXPLAINおよびEXPLAIN ANALYZEについて。良エントリ。
  • [PostgreSQLウォッチ]第17回 新しい実行プラン・タイプによるPostgreSQL 8.1の性能向上

    前回は開発中のPostgreSQL 8.1で,バッファ・マネージャに改良が加えられて,大幅な性能向上があったことを述べた。今回は同じく性能面で大きな前進となるビットマップ・ベースの実行プラン・タイプが追加されたことを報告する。なお,稿で検証に使用したのは5月3日時点のバージョンである。 オプティマイザと実行プラン その前に,PostgreSQLにおけるオプティマイザと実行プランについて復習しておこう。 テーブルにはアクセスを高速化するためにインデックスを追加することができる。インデックスとは日語で「索引」のことである。例えば書籍を例にとって考えてみよう。ある書籍の中から,「神奈川県」について書かれたページを探したいとする。もし索引がなければ書籍の1ページ目から丹念に読んでいくしかない。しかし索引があれば,「神奈川県」について書かれたページがすぐに分かるので,素早く目的のページにたどり着

    [PostgreSQLウォッチ]第17回 新しい実行プラン・タイプによるPostgreSQL 8.1の性能向上
  • PostgreSQL 8.3.6文書

  • http://neta.ywcafe.net/000960.html

  • PostgreSQLの組み込み関数

    ■ PostgreSQLの組み込み関数 PostgreSQLには数多くの組み込み関数があります。ここでは主な関数を掲げておきます。なお、○印はSQL92互換の関数、▲印は関数名が同じでも指定の書き方が異なるものです。 ■ 集約関数

    agw
    agw 2010/01/15
    組み込み関数の表。
  • 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システムではイマイチスマートじゃない(と思うの

    agw
    agw 2010/01/15
    これは使えそう。
  • [ThinkIT] 第3回:VACUUMの活用によるチューニング (1/2)

    VACUUMは他のデータベースにはないPostgreSQL固有のコマンドであり、使い方次第でPostgreSQLの性能を左右する重要な役割を持ちます。 PostgreSQLでは、削除や更新が行われても古い行は消えません。VACUUMコマンドは、このような古い行の中から、どのトランザクションからも参照されていない安全に再利用できる行を探して、FSM(Free Space Map)という共有メモリ上のデータ構造にその位置と大きさを記録します。追加や更新など、新しく行を追加する場合はまずFSMを検索して、新しいデータを保管するのに適当な大きさの行が見つかればそれが再利用されます(図3)。

  • [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トラブルシューティング探偵団のリーダーは務まらん。

    PostgreSQLを遅くしている犯人はどこだ?
    agw
    agw 2008/06/13
    大変参考になりました。
  • 1