select to_timestamp(1188831600); → "2007-09-04 00:00:00+09"select extract(epoch from timestamp '2007-09-04'); → 1188831600MySQLとかではどうなんだろ?
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
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
by 柴田 淳 — posted at 2005-10-19 23:56 last modified 2006-12-04 12:41 「水曜日」とか口走ったせいで、いきなり自分の首が絞まっている気がします。 月曜日に言うんじゃなかった。。。でも、とりあえず頑張ります。 さて、パフォーマンスのチューニングと言った場合に、非常に大きなウェイトを占めるのがSQLのチューニングだと思います。アプリケーションがカッチリと固まってしまってからだと大きな変更は難しいものの、それでもやはりパフォーマンスへの影響は大きいでしょう。 SQLのチューニングをする場合、一般的には以下のようなプロセスを踏んで作業を行うことになると思います。 重いSQL文の特定そのSQL文が遅い原因追求SQL文の改善チューニング効果の確認 今回は、処理時間のかかるSQL文をどうやって特定するかを考えてみます。 例えば、アプリケー
ダンプ & リストアには様々な利点がある。万が一のサーバクラッシュへの備えや、マシン間でのデータベース移植にはもちろん。しかしそれだけでない。ファイルというポータブルな形にしてしまえばバックアップは簡単。さらに、PostgreSQL のバージョンアップの際には、リストア時に新しいサーバプログラムが構造を適宜変換して取り込むので、バージョンによるデータ互換性問題も、たいてい解決してくれる。日常的には当然だが、 PostgreSQL をバージョンアップする前には必ずダンプを取っておこう。 データベースのダンプ データそのものやテーブル構造をまるごとファイルに書き出すことができる。ファイルに書き出されるのは、リストアに必要なSQLコマンド。一切合切をいっぺんにダンプできる pg_dumpall を使う方法もある。 コマンド書式: pg_dump options database > ダンプ先fi
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 8.1で,バッファ・マネージャに改良が加えられて,大幅な性能向上があったことを述べた。今回は同じく性能面で大きな前進となるビットマップ・ベースの実行プラン・タイプが追加されたことを報告する。なお,本稿で検証に使用したのは5月3日時点のバージョンである。 オプティマイザと実行プラン その前に,PostgreSQLにおけるオプティマイザと実行プランについて復習しておこう。 テーブルにはアクセスを高速化するためにインデックスを追加することができる。インデックスとは日本語で「索引」のことである。例えば書籍を例にとって考えてみよう。ある書籍の中から,「神奈川県」について書かれたページを探したいとする。もし索引がなければ書籍の1ページ目から丹念に読んでいくしかない。しかし索引があれば,「神奈川県」について書かれたページがすぐに分かるので,素早く目的のページにたどり着
パラメータの設定方法 パラメータの設定は以下により行うことができます。 postgresql.conf ファイル postmaster 起動時の引数 ALTER DATABASE SET コマンド ALTER USER SET コマンド SET コマンド PGOPTIONS 環境変数 パラメータ値の型がstringで空白が必要な場合は、シングルコートで囲みます。 パラメータ値の型がbooleanの場合は、on | off | true | false | yes | no | 1 | 0の表現が可能ですが、このドキュメントではon | offで記述します。 設定したパラメータの確認は以下により行うことができます。 SHOW コマンド pg_settings 仮想テーブルの参照 postgresql.conf ファイル postgresql.confファイルはパラメータ設定を行うテキスト
Copyright (C) Mainichi Communications Inc. All rights reserved. 掲載記事の無断転載を禁じます
# -------------------------------------- # ポストグレスメンテナンス # -------------------------------------- PostgreSQLは追記型のデータベースです。 updateやdeleteを行っても物理的にデータが削除されるわけではありません。 不要になったデータを削除するためにはvacuum処理が必要です。 vacuum処理には下記の2種類があります。 スーパーユーザ(postgresなど)で行ってください。 PostgreSQL の VACUUM コマンドは以下の理由より定期的に実行させる必要があります。 ・更新、あるいは、削除された行によって占められたディスク領域の復旧。 ・PostgreSQL 問い合わせプランナによって使用されるデータ統計情報の更新。 ・トランザクション ID の送り込みによる非常に
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システムではイマイチスマートじゃない(と思うの
ここまでは単一の列に対して作成するインデックスを前提にお話ししてきました。しかし、インデックスは同一テーブルの複数の列に対してまとめて設定することもできます。検索条件に複数列を指定する場合などは、このようなインデックスを使えばさらに効率よく処理を行うことができます。
インデックス(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 近年、リモートワーク
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く