select to_timestamp(1188831600); → "2007-09-04 00:00:00+09"select extract(epoch from timestamp '2007-09-04'); → 1188831600MySQLとかではどうなんだろ？
Pg は昔からちゃんとトランザクション対応です。 Pg なら Perl DBI で AutoCommit を 0 (disable) にできます。 MySQL を使ってない理由は、トランザクション非対応だったということよりも文化の問題が大きい。 SELECT は高速らしいけど低機能という印象もさることながら、 なによりコマンドラインインターフェースの体系が使いにくかった。 Pg のコマンドラインインターフェースに慣れてしまっていると、 MySQLのそれには馴染めなかった。 MySQL は速度重視のためにあえてトランザクション非対応というけれど、 Pg より速いと実感できるほどのデータ量がうちにはない。 MySQL は 4.0.x からトランザクション対応になった。 テーブルを作るときにトランザクション対応/非対応を選べるようになった。結局、速度より信頼性を選択したのか。 Linux には
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 の送り込みによる非常に
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 の管理 データのバックアップ 日々データベースを運用し、安全面を考えると、データベースのバックアップは当然必要となってきます。バックアップの方法には複数通りあります。 data ディレクトリごとバックアップをとる pg_dump コマンドを使う 一番目の方法は、非常に手っ取り早いものです。PostgreSQL のデータファイルは、普通のファイルですので、OS に付いているバックアップツールを使ってバックアップをしてしまう方法です。tar コマンドや、cp コマンドや、その他のツールを使って PostgreSQL の data ディレクトリをバックアップしまいます。ただし、バックアップ中にデータが変更されるとまずいので、必ずデータベースを停止した状態でバックアップします。したがって、この方法は、バックアップ時にデータベースが停止してもかまわないような環境で利用できます。
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システムではイマイチスマートじゃない(と思うの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
