パスワードを忘れた？ アカウント作成
Close
9518 story

PostgreSQL 8.0 リリース 114

ストーリー by Oliver
BEGIN-UPGRADE 部門より

L.star 曰く、 "オープンソースのデータベースとして有名なPostgreSQLの新しいバージョン、8.0がついにリリースされた。7.4から１年２ヶ月、ベータテストから４ヶ月半という長い開発期間の後とあって、さすがにたくさんの新機能が盛り込まれている。

Windows 2000/XP用サーバーの公式サポート
ただし、他のプラットフォームより枯れていない点に注意。なお、Windowsインストーラー形式のバイナリはpginstallerにて配布されている
Savepoint
トランザクションの一部をロールバックすることが可能に。
Point In Time Recovery
差分バックアップやロールフォワードといったデータ保護機能が強化された。
Tablespace
ディスク上の配置を固定ディレクトリでなく移動可能にする。これによりI/Oの分散も期待できる
パフォーマンス改善
特にバッファアルゴリズムが刷新されたこと、バックグラウンドのディスク書き込みプロセス、VACUUM時のキャッシュ利用の改善など。
その他多数
ログの扱いの改良、CSVの入出力、カラムの型の変更がALTER TABLEで可能になったこと、インデックスの改善、統計情報更新のanalyzeコマンドのサンプリング手法が一新、など

特に今回組み込まれた機能は商用DBにあってPostgreSQLになかったものも多く、よりPostgreSQLが広範囲にわたって使われる一歩になるのではないだろうか。ダウンロードはftpサイトの他にBitTorrentからも可能である。"

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

PostgreSQL 8.0 リリース More

  • SQLそのもの (スコア:3, すばらしい洞察)

    by Anonymous Coward on 2005年01月19日 22時10分 (#681394)
    PostgreSQLでもMySQLでもOracleでも、まあなんでもいいんだが、どの本を手にとってもインストールの仕方か高度なチューニングの話かどちらかに偏っていて、実際のSQLというものそのものについて解説した本もWebサイトも世の中にないような気がするのはなぜだ。

    要はデータベース設計とそれをSQLに落とし込むところを熱く語った本がほしいのだが良書が見つからぬ・・・

    ちなみに拙者は情報工学系・計算機工学系ではないので「そんなの大学の専門課程で常識だろ」とか言われても困る

    • Re:SQLそのもの (スコア:3, 参考になる)

      by Anonymous Coward on 2005年01月19日 22時51分 (#681409)
      プログラマのためのSQL　第2版 [pearsoned.co.jp]なんかはどうでしょう？

      SQLはそれなりに書けるが、これが最良の方法なのか？ と疑問を持ち始めている方には良い本だと思います。
      シェア
      親コメント

    • Re:SQLそのもの (スコア:1)

      by kogekoge (20427) on 2005年01月19日 23時28分 (#681421) 日記
      SQLそのものは他の方も書いている本など、あふれるほどあるので
      問題ないとして、データベース設計(データモデリング)の本は、
      それと比べてはるかに少ないのが現状。
      現場で良き師に出会って体で覚えるしかないかも。
      正規化とかの基本的な理屈を説明する読みやすい本が増えたから、
      そういう意味ではかなり環境は良くなったけど。
      シェア
      親コメント

  • PL/pgSQL で Exception の実装 (スコア:2, 興味深い)

    by NaruTo (1519) on 2005年01月19日 16時43分 (#681230) ホームページ 日記
    個人的にはこれが一番ありがたいな。

    35.7.5. Trapping Errors [postgresql.org]
    --
    マクロの基本は検索置換(by y.mikome)

  • 個人的には (スコア:2, 興味深い)

    by mikanjapan (23786) on 2005年01月20日 7時59分 (#681530)
    部分ロールバックも嬉しいが、とにかくVACUUMレスにして欲しい。
    あとインデックスを含んだpg_restoreの高速化とか…無理か。

    #面倒なので、OSごとHDDのミラーリング+イメージで対応してます。

    • Re:個人的には (スコア:3, 興味深い)

      by bytes (17046) on 2005年01月20日 8時47分 (#681533)
      追記型アーキテクチャである限り、VACUUM レスは難しいだろうなぁ。その代わりに MVCC があったりロールバックセグメントの管理をしなくて良かったりするわけで (最近は Oracle も自動 UNDO 管理が普通のようですけど)、まぁここは設計上のトレードオフだと思って受け入れるしかないのでは。

      Oracle でも一つの DB をずっと使ってると行移行とかハイウォーターマークの問題とかいろいろあるわけで、データファイルの定期的なメンテナンスはいずれにせよ必須なのではないかしら。

      インデックスを含むテーブルへの高速 import 手段は確かに欲しい！
      ８はまだ見てませんけど 7.4.6 までは大量投入時は drop index してからやる、というのが常識化しているくらい遅いですからね。drop index→copy→create index ならば常識的な時間で処理できるんだから、内部でそれと同じことをやればいいだけだと思うんだけど…。
      シェア
      親コメント

      • Re:個人的には (スコア:2, 興味深い)

        by uchida-t (14803) on 2005年01月20日 13時37分 (#681650)

        追記型の宿命のVACUUMに関しては、普段はコンカレントVACUUMで誤魔化しておき、定期的にフルVACUUMするしかないんでしょうねぇ。フルVACUUM中でもテーブルロックがかかるだけで参照はできるわけですから、運用次第でカバーできなくもないわけですし。

        あと、Oracle Developer DaysでのOracleとPostgreSQLとの比較 [atmarkit.co.jp]でPostgreSQLの問題点がいろいろ指摘されましたが、8.0になってTablespaceの導入によるI/Oの分散とパフォーマンスの改善が可能になり、SavepointとPoint In Time Recoveryによりバックアップ・リカバリも大分改善されましたから、今度このような講演をする際は材料探しに苦労しそうです:-)

        シェア
        親コメント

      • Re:個人的には (スコア:1)

        by L.star (163) on 2005年01月20日 11時11分 (#681588) ホームページ
        drop index→copy→create index ならば常識的な時間で処理できるんだから、内部でそれと同じことをやればいいだけだと思うんだけど…。
        それを自動でやると、複数接続から同時にユニーク制約を持ったテーブルにデータを挿入したときに、整合性を保証出来ません。

        # 接続が単数だけからしかこないとは限らないのが頭の痛いところ

        人間が判断するから・・・だと、若干面倒だとは思いますが、別にcreate->dropでもいいですよね。

        シェア
        親コメント

        • Re:個人的には (スコア:1)

          by bytes (17046) on 2005年01月20日 20時18分 (#681760)
          > それを自動でやると、複数接続から同時にユニーク制約を持ったテーブルにデータを挿入したときに、整合性を保証出来ません。

          確かにおっしゃる通り。
          でも実は、PostgreSQL は DDL もトランザクションに含めることが出来ちゃったりするので「drop index→copy→create index」を１つのトランザクションとして実装すれば、(最初の drop の時点でロックがかかり) 大丈夫だったりします(笑。これはほとんど裏技だなぁ。
          シェア
          親コメント

          • Re:個人的には (スコア:1)

            by L.star (163) on 2005年01月20日 21時07分 (#681768) ホームページ
            いいえ、それでも元々データが１件以上入っていた場合破綻します。

            もう一つ上げておきましょう。DROP->COPY->CREATEとした場合としない場合、どっちが早いかはCOPYの量に依存しますが、当然そのシーケンスの中で、ロックを取る前にインデックス再作成した方が早いかどうかを知ることはできません。極論、レコードを１つも挿入しないのに事実上のREINDEX相当を行うというばかげた事態になります。

            ちなみに、pg_dumpもpg_restoreも、今のバージョンは全てのデータが投入されるまでindexを作成する処理は行いませんから、同等の処理は成されているはずなんですが・・・

            シェア
            親コメント

            • Re:個人的には (スコア:2, 参考になる)

              by bytes (17046) on 2005年01月21日 9時57分 (#681970)
              なんだかディープな話になってますね(笑。お付き合いいただき恐縮です。

              > いいえ、それでも元々データが１件以上入っていた場合破綻します。

              そうでしょうか？ちょっとテストしてみました。

              => \d test_table
                Table "public.test_table"
              Column |  Type   | Modifiers
              ーーーーーーーーーーーーーーーー
              id     | integer |
              Indexes:
                  "test_table_id_key" unique, btree (id)

              // unique 制約だとちと面倒なので単なる unique index として用意。

              => select * from test_table;
              id
              ----
                1
              (1 row)

              => begin;
              BEGIN
              => drop index test_table_id_key;
              DROP INDEX

              // ここで他の接続から同じように begin、drop index しても
              // lock されているため待たされる。ちなみに select も待た
              // される＜ダメじゃん！(笑。

              => \copy test_table from test_table.dump
              \.
              => select * from test_table;
              id
              ----
                1
                1
              (2 rows)

              // わざと unique 制約違反なデータを copy

              => create unique index test_table_id_key on test_table(id);
              ERROR:  could not create unique index
              DETAIL:  Table contains duplicated values.
              => commit;
              COMMIT

              // あれ？「WARNING:  there is no transaction in progress」
              // が出ないけど…

              => select * from test_table;
              id
              ----
                1
              (1 row)

              => \d test_table
                Table "public.test_table"
              Column |  Type   | Modifiers
              ーーーーーーーーーーーーーーーー
              id     | integer |
              Indexes:
                  "test_table_id_key" unique, btree (id)

              // ちゃんとロールバックされてる。

              なんとなく僕にはちゃんと動いているように思えるんですが (まぁ select も lock してしまっているのは置いておくとして)、どのような場合に破綻してしまうのか教えていただけますか？

              > DROP->COPY->CREATEとした場合としない場合、どっちが早いかはCOPYの量に依存します

              それはそうですね。ごく単純に上記処理を行ってしまうといろいろもったいないことが起きてしまうことは分かります。本当にシステムに組み込む場合はもう少し凝ったことをしてあげた方が良いでしょう。

              例えば、僕は上記の「drop→copy→create」が単一の import 用コマンドで行われていることを想定していますが、それならば drop 前に copy されるデータのサイズ等を知ることも可能なはずですから、それによって処理を分けるとか、

              あるいはさらに、DB 自体を工夫して「index 更新なしの copy」と「新規追加された部分のみ index 追加」を行えるようにするといったことを想像していました。

              > ちなみに、pg_dumpもpg_restoreも、今のバージョンは全てのデータが投入されるまでindexを作成する処理は行いませんから、同等の処理は成されているはずなんですが・・・

              フルダンプ、フルリストア時はさすがに考慮されているのですね。そこは未検証でした。どうもありがとうございます。

              僕の元々の書き込みは「インデックスを含むテーブルへの高速 import 手段は確かに欲しい！」ということでしたので、主に copy from が使われるような局面での高速化についての話でした。
              シェア
              親コメント

  • 日本語版 (スコア:1, 参考になる)

    by Anonymous Coward on 2005年01月19日 16時34分 (#681223)
    日本語版もあるみたいですね。

    個人的には英語版でも利用できるのですが、DBを教えていて、
    日本語インストーラとかWindows版がないと、拒否反応を示し
    ている連中が多いので、ぜひ日本語版もほしい。

    そういった意味では、Win対応が増えると潜在的なユーザも
    増えるのかな？

    • Re:日本語版 (スコア:1, すばらしい洞察)

      by Anonymous Coward on 2005年01月19日 16時47分 (#681232)
      >DBを教えていて、
      >日本語インストーラとかWindows版がないと、拒否反応を示し
      >ている連中が多いので、

      そーゆー連中は、なんだかんだ別のところで躓くと思いますけどね。
      シェア
      親コメント

    • Re:日本語版 (スコア:1)

      by goji (949) on 2005年01月19日 17時43分 (#681262) ホームページ 日記
      ソフトウェアがローカライズされていると、i18nにもコスト掛けたんだろうな、と気休めになってます。
      シェア
      親コメント

  • 多重化 (スコア:1)

    by chapuni (1170) on 2005年01月19日 18時40分 (#681292) ホームページ 日記

    あとはクラスタリングができると、応用範囲が広がるよなぁ。個人的にはPostgeSQLは馴れ初めだったので、ぜひPostgres主体に戻ってみたい。まずはあれこれ評価から始めよう。

    あー、実験で入れて、うまく動かなくて外したpgclusterをどうにかしなくちゃー(汗

  • Windowsに正式対応になって、業務系アプリで使いやすそうだなーと思ってます。
    安定するまではもうちょっと時間がかかりそうですが・・・。

    やっぱり業務系のアプリだとWindowsが主流ですし、ORACLEやDBやMS-SQLサーバーの代わりに使えるDBになってくれることを期待してます！

    中小企業向けアプリケーション向けで、PostgreSQLをアプライアンスサーバーとして、提供するなんてのもどっかやらないですかね。
    --
    --
typodupeerror

Stableって古いって意味だっけ？ -- Debian初級