パスワードを忘れた? アカウント作成
11203 story

PostgreSQL 8.1リリース 33

ストーリー by yoosee
ゆけゆけぼくらのポストグレスー 部門より

L.star曰く、"PostgreSQLの新バージョン、8.1がリリースされている。8.0に続き今年度2回目のメジャーバージョンアップだが、これはむしろ8.0が遅れたもので、7.3,7.4とリリースは毎年11月に行われており、それに戻った形だ。リリースの詳細については プレスキットを参照されたし。

主な改善としては、

  • 権限管理がuser/groupからより自由度の高いroleベースに
  • 関数のINOUTパラメーター(入力と出力の両方に使う)
  • 複数のシステムでトランザクション同期を行うために必須な機能である、二相コミット
  • 基礎的なテーブル・パーテーショニング機能
  • 自動バキューム機能の搭載。これは従来contribに収録されていたものの改良版だが、vacuumを自動で発行するものであり、vacuum不要になったわけではない
  • バッファリングにおけるgiant lockを排除、max()/min()に対するindexの使用、新しいアクセスメソッドBitmapScanなど、広範囲なパフォーマンス改善
  • 64bit サポートの改善で、2GBを超えるメモリを割り当てられるようになった。

今回の追加機能は前バージョンに比べるとかなり地味だが、パフォーマンス改善がかなり効いており、「8.1はパフォーマンスがよい」と評判が高い。特に複数CPU,大量メモリを搭載したマシンでは大幅向上が見込めるだろう。"

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by kawaz (15398) on 2005年11月10日 0時41分 (#829173) ホームページ
    8.0で待望のWindows版が出ましたが、実はWindows版ではデータベースのエンコーディングに UTF-8 が選択できないという問題がありました。これにはガッカリしたものです。WindowsがサポートするUTF-8のマッピングが何か問題があってどうこうとか言う話だった気がしますが…。

    しかし 8.1 にしてみたらあっさり UTF-8 が選択できるようになっていてとても嬉しいです。
    内部的な話は良く知らないんですが結局どんな問題でどう解決したんでしょうかね?
    • pgadminでみたら8.0でデータベースのエンコーディングにUNICODEとなってますね。
      このことではなくて?

      データベースのバックアップとるとUTF8で書き出されてるので特に問題はないですが。
    • Windows版を出した時点でデータベースのことが分かっていません。Windowsはクライアントではよいが、サーバのプラットフォームに使えるようなOSではありません。 目先の欲に眩んでWindowsへの移植なんかしたんでしょうね。
      • by Anonymous Coward on 2005年11月12日 11時51分 (#830403)
        「そこにニーズがあるから」

        というのが理由でしょう。

         実際にDBを使った簡単なアプリに、それを使うだけで、プログラムを書き換えることなく小規模から中規模にいたるスケーラビリティを与えてくれるというのは非常に魅力的だと思います。

         今までJETなどを使っていたような用途にも使い慣れたPostgreSQLが使えるとなると私なんかは非常に魅力的なソリューションと思えます。
        親コメント
      • またお前か。
  • by t_mrc-ct (5292) on 2005年11月09日 18時30分 (#828947) 日記
    必要な機能を8.1に間に合わせるために資金提供があった [itmedia.co.jp]らしいですね。
    プレスキット [postgresql.jp]を見るかぎりでは(共有行ロックとGiSTかな?)間に合ったみたい。
  • PostgreSQL 8.1は“速い”というもっぱらのウワサ [atmarkit.co.jp]
    ちょっと前に@ITで記事になってましたね。

    丁度Postgre使うプロジェクトやっているので試してみたい・・・
    ちょっと人柱になるのが怖い気もするけど・・・

    重蔵。
    • MySQL5.0リリース [srad.jp]から気になり始めたのですが、多機能になり始めたMySQLとパフォーマンスも良くなり始めたPostgreSQL、だんだん似たり寄ったりになって来ているのではないでしょうか。

      早いからMySQLを使うとか、この機能が使いたいからPostgreSQLを使うとか明確な理由が無くなってきたような気がします。

      私はRDBMSを使って何かを開発とかした事がないので良く分かりませんが明確な用途の使い分けってあるのでしょうか?

      親コメント
      • >明確な用途の使い分けってあるのでしょうか?

         特には無いんじゃ無いでしょうか?
         MySQLは海外で多く使われていますね。
         逆にPostgreSQLは日本で多く使われています。
         なのでPostgreSQLは日本語情報が多いというメリットはありますね

         一応仕事で両方使いましたがMySQLはサブクエリーが使えなかったり
         (最近の4.1系からは使える様になったみたいです)
         トランザクションを使う場合はInnoDBを指定しないといけなかったり
            (3系の頃はオプション扱い)
         日本語にやや難があったり(4.1から?)とちょっとなぁと思う点もありました。
         最近のOracleがInnoDBを買収した件もちょっと今後に不安がありますね。
         MySQL派の方の反論お待ちしてます。

         PostgreSQLの方は8からはWindows版も出ましたし
         機能的に見ても商用DBといい勝負していると思ってます。
         クライアントの日本語化、日本語情報の多さで自分的には
         PostgreSQLを押しますね。

         重蔵。
        親コメント
        • by Anonymous Coward on 2005年11月09日 23時30分 (#829125)
          MySQL派なのでMySQLを押してみます。

          個人的には、MySQLはいい具合に枯れている点、過去のリリースへの保守が商用DB以上に長い点が気にいっています。
          PostgreSQLは、頻繁にバージョンアップすることが良いところでもあるわけですが、長期運用を考えると頭が痛いことも多いです。特にストアドプロシージャに依存したアプリケーションのお陰で、穴だらけ、バグだらけ、バキュームをかけるたびにインデックス破損しているよというようなエラーを出すような7.2系をずっと運用させられるような悲劇を進行中です。(涙。

          また、MySQLは、数百万、数千万行のテーブルを扱う場合などに関しても、PostgreSQLに比べて、安心感がありますね。
          PostgreSQLの8系はまだ評価していないんですが、7系では、数百万行のテーブルですら、使い物にならないことも多々ありました。(テーブルの構成に寄るところも大きいんですが、インデックスを使った検索はそれなりに使えるんですが、少しでも外れると全然ダメですね。)
          MySQLでは、MyISAM・InnDB問わず、数百万件くらいのテーブルであれば、日常的に使っていますね。経験的に、InnoDBであれば、数千万、MyISAMであれば、数億までは普通に使えるという感じがします。

          それから、最もMySQLを押す大きな理由としては、簡単で安定しているレプリケーション機能でしょうか。これのお陰で、スナップショットを取ったり、事実上のホットバックアップとして構成したりと、運用が非常に楽です。
          PostgreSQLの場合、Slony-Iはテーブルの構成を変えたり、トリガーをつけたりと、何かと面倒ですし、PGclusterは安定しない万年ベータ版ですから、もう少し良いソリューションが欲しいところです。

          ちなみに、ドキュメントに関しても、MySQLは、言うほど少なくない気がします。
          PostgreSQLのオンラインリファレンスくらいのものであれば、dev.mysql.comにある程度は翻訳版がありますし、何よりPostgreSQLってあるラインを超える情報が異常に少ないんですよね。具体的には、パフォーマンスチューニング関係など。S○A方面にはたくさんあるらしいですけど、オンラインでは日本語は当然として英語でも、はたまた書籍でも見かけませんね。PostgreSQLをインストールしてPHPから使ってみよう系は多数あるんですが、最低限として、「実践ハイパフォーマンスMySQL」程度のPostgreSQL情報が欲しいんですが。誰か良い書籍や情報ソースを教えてください。
          親コメント
          • by Anonymous Coward on 2005年11月10日 0時05分 (#829150)
            どっちも使いましたけど、MySQLだってバージョン変わると結構ちがいますよ。というか正式版出た後もかなり4.1はバグ大量で苦しみましたが。一方PostgreSQLも8.0でたばかりはJDBCドライバがダメダメでした。

            PostgreSQLは7.xは捨てていいんじゃないでしょうか。速度的にもスケーラビリティ的にも8.0は段違いです。話題の種でも合ったバキューム問題とインデックス使用問題がほぼ消えています。

            一方MySQLは従来のユーザーは4.0で止めておいたほうが無難ですが、サブクエリーは便利なんですよね。

            ストアドプロシージャは3層式ならメリットは大分少ないので、依存しそうなガリガリのコードを書くよりはマシンのスペックあげたり追加したほうがいいかと思われます。商用DBに比べればソフトウェアのライセンス代は問題になりにくいですし、結局チューニングとしての人件費のほうがはるかにかかる場合も今となってはわりと多いです。

            あと、postgreSQLでレプリケーションってほとんどの人はpgpool使ってると思います。

            PostgreSQLのほうがパラメータチューニングしやすいような気がしますし、Windows版での比較ならPostgreSQLのほうが分かりやすいと思います。pgadmin3がセットアップされるのですぐにAccessのように表形式でデータ入れていったりするのは便利です。

            書籍としてはMySQLのほうが入手性がいいと思いますし、私もPostgreSQLの本のほうが実際手持ちは少ないですが、特に困りませんね。SQLやらそういうのはもうだいたいどうでもいいレベルで、セットアップとバックアップ槍ストアなどの運用の仕方やノウハウだけが重要ですが、このへんはあまり本では触れてなかったりします。

            どちらにしろある程度の規模になるとOracleをお客さんが指名してきますし、中小規模はもうフリーのプロダクトで十分な感じです。
            親コメント
          • >>最低限として、「実践ハイパフォーマンスMySQL」程度の
            >>PostgreSQL情報が欲しいんですが。
            >>誰か良い書籍や情報ソースを教えてください。

            amazon.co.jpで調べれば?評判のいいのがいくつかみつかるはずだけどな。
            • >>最低限として、「実践ハイパフォーマンスMySQL」程度の
              >>PostgreSQL情報が欲しいんですが。
              >>誰か良い書籍や情報ソースを教えてください。

              amazon.co.jpで調べれば?評判のいいのがいくつかみつかるはずだけどな。

              具体的にどれですか?
              元AC では無いですけれど、私も知りたいので教えてください。
              御存知であれば「MySQLクックブック」相当の本も一緒に教えていただきたいのですけど。

              • by Anonymous Coward on 2005年11月10日 21時08分 (#829499)
                えっと、そうですか?。商用DBでは多数見かけるのですが…。
                例えば、OracleやDB2に関しては、翔泳社やピアソン辺りがいろいろ出していますよ。あまり目立ちませんが、Oracleはオライリも色々出していますね。

                4.1の日本語問題は、意外と皆さん苦労しているみたいなんですね。
                私のところは、逆にPostgreSQLオンリーだったのを、新規案件でMySQLに移行した口なんですが、日本語問題に関わるのが嫌だった為、これをいい機会だとして、アプリケーションの内部で使用する文字コードをutf8に統一させました。
                ついでに、運用が地獄を見るから辞めてくれと言われながらも、「ストアドの方が速いし、コード(の見た目)が綺麗」とかいう、運用する方からはさっぱり理解できない理由でストアドを使いたがる開発者から、ストアドを取り上げることもできて、一石二鳥でした。(苦笑

                でもまあ、パフォーマンスやデータ量の要件がシビアじゃなくて、運用をあまり気にしなくてよい開発であったり、DBに色々なものを求めるのであれば、PostgreSQLの方がよいとも思います。楽ですし。
                ただし、Oracleのタダ版が出た今現在に関しては、そっちが気になっています。DBがボトルネックになったら、アプリケーションはそのままで、大規模用(クラスタ)へアップグレード出来るのは魅力的ですね。
                親コメント
              • 勘違いしているようですが、4.1の文字コード問題はUTF8にしても解決しないものでしたよ。

                EUCな環境はごまかしで使えないこともないのですが、Winな環境ではそれはそれはすさまじい回避方法(になってないレベル)しかなかったのです。

                ストアド依存は特にマシンが低スペックだったときにOracleでガリガリやっていた人種に多いですが、運用コストが高いですよね。ストアドとJavaなどの言語の2つの出来る人種を用意しなければなりませんから。

                場合によっては自分以外保守できないようにして地位を確保しようとしてる人もわりといますが・・・。
              • >「ストアドの方が速いし、コード(の見た目)が綺麗」とかいう、運用する方からはさっぱり理解できない理由

                理解できないということが理解できません。
              • ストアドプロシージャが "速い" というのは多分そうなのでしょうけれど、
                "綺麗" だというのは、いったい何と比較するとそう言えるのでしょうか?
                親コメント
              • Oracleでロジックが複雑になるコードをストアドでまわしてるのをみたことがあります。
                とんでもなく非効率なコードで見にくさはすごいですね。

                最近はDBは単なるストレージで、ロジックはアプリ鯖などに完全に任せるのが多いのでストアドはほとんど使いませんね。

                パフォーマンスにしてもIO類がネックなのかロジックがネックなのかによりますが、アプリ鯖なら複数増やせばパフォーマンス上がっていきますから、DBには余計な仕事させたくないですね。
              • DB屋の漏れとしては黙っちゃいられね。

                設計的には美しいとかあるのかも知れないが、ORマッパー AP鯖の吐き出す、糞なSQLはどうよ?

                パフォーマンスでないのにはそっち側のSQLの質の問題もあるでそ。

                ストアドだと1呼び出しですむようなのが何百、何千ものSQL吐いていたのも見た事があるのですが。
        • by Anonymous Coward on 2005年11月09日 22時26分 (#829084)
          土俵が違うという段階で勝負になりません。 データ量が多い場合や、ハードウェアに対するスケーラビリティを考えると PostgreSQL はまだまだはるかに及びません。 コンカレントバキュームが効率的に適用が可能なデータベースサイズも小さ過ぎます。
          親コメント
    • 8.1以前に7.xから8.0になっただけでもびっくりするくらい速くなってますね。
      バキューム周りもやっと現実的になったのも8.0からですし、これを7.5として出さなかったのは正解でしたね。
  • やっと… (スコア:2, 参考になる)

    >max()/min()に対するindexの使用

    やっとそうなったのか…。
    これのおかげで、
    select * from tbl order by score desc limit 1;
    なんてやってる部分があるわけだけど、素直にクエリが組めるようになるって嬉しいな(笑

    …リプレース計画が立つのは相当後だろうけど。
  • by iwa (2980) on 2005年11月09日 19時54分 (#828979)
    これって完治しないのかな?
    ぐぐってみると、昔から問題になっているようなんだけど……。
    (関連情報: 1 [picolix.jp], 2 [net-newbie.com])
    • by L.star (163) on 2005年11月09日 23時12分 (#829110) ホームページ
      しませんね。この辺は欧米人かそうでないかで結構考えていることが違う部分があって、そもそも--no-localeが必要になる以前からも、locale周りでは議論が続いています。

      とくに、国際化担当にlocale賛成派のPeterがなっちゃったし、当面変わらないんじゃないでしょうか。

      #っていうか、glibcの問題とか言う話とかなのかなぁ

      親コメント
  • delete関係 (スコア:1, 興味深い)

    by Anonymous Coward on 2005年11月09日 19時55分 (#828980)
    delete関連のアレが速くなったのなら直ちに 全部リプレースなのだが
    やっぱり再構築による定期的なメンテは必須だろうな
  • by Anonymous Coward on 2005年11月10日 11時21分 (#829305)
    これって、SQL99 にはどの程度対応しているのかな。
    あと、SQL99に完全準拠しているDBエンジンってどれくらいあるのでしょう?

    教えて、得ろイ人!
    • Re:SQL99 (スコア:3, 参考になる)

      by Anonymous Coward on 2005年11月10日 21時53分 (#829524)
      http://www.postgresql.org/docs/8.1/interactive/unsupported-features-sql-standard.html こんな感じのようです
      親コメント
  • by Anonymous Coward on 2005年11月11日 1時09分 (#829639)
    そろそろJDBCまともな実装がほしい。
    MySQLにもいえることだけど。

    JDBC3対応してるかどうかで大幅に使い勝手が変わりますからね。
typodupeerror

にわかな奴ほど語りたがる -- あるハッカー

読み込み中...