パスワードを忘れた? アカウント作成
115669 submission
データベース

PostgreSQL 8.4リリース 26

タレコミ by Driver
Driver 曰く、
PostgreSQLの新バージョン、8.4が6月29日にリリースされた。
前バージョンの 8.3から約15ヶ月ぶりのメジャーバージョンアップとなる。
今回のポイントは
  • ウィンドウ関数実装
  • 再帰クエリの対応
  • 並列リストア
  • カラムパーミッション
  • ロケールをDB毎に実装(今まではinitdb時にしか指定できなかった)
  • ハッシュIndexの性能向上
  • EXISTS、NOTEXISTSの性能向上(INを使った場合よりパフォーマンスが悪かった)
  • FreeSpaceMapの自動サイジング
  • SSLの証明書認証対応
  • その他諸々・・・

だが、前回のバージョンアップまで、auto vacuumは毎回テコ入れされていたが、十分な機能となったためか今回のバージョンでは新機能の追加と「auto vacuum以外のテコ入れ」となっている。
詳細はリリースノートを確認下さい。

個人的には「並列リストア」くらいしか気になる点はなかったが、再帰クエリもテーブル構造次第では非常に有益だと思う。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • ログファイルのメッセージで、ローカル側のメッセージがcp932で、サーバ側からのメッセージがutf8で出力され困ってしまいます。 今のところ、設定ファイルによる回避策は見つかりません…
    • by Anonymous Coward
      本気で必要ならソース編集してコンパイルし直せば?
      その位なら別に難しくはあるまい?

      #ま、設定ファイルで変更可であったら‥という希望は分かるが。
  • by Anonymous Coward on 2009年07月03日 15時27分 (#1598841)
    8.4 Released [postgresql.jp]
    新機能解説 [postgresql.jp]

    # 8.3のときは自動で型キャストしなくなったと聞いて見送ったのですが、8.4はどうでしょうか
  • by Tatenon (20311) on 2009年07月03日 16時45分 (#1598893) 日記
    『ASが省略可能になった』
    が個人的には一番インパクトあるかも。

    あと3ヶ月早ければ・・・・orz

    # でも苦労したからタレコミの内容がわかるようになっててちょっと嬉しい。
  • ホットスタンバイと同期レプリケーションが 8.5 へ繰り延べになった
    ことが残念でならない(PostgreSQL 8.4 の新機能 — Let's Postgres [postgresql.jp])。
    貧乏性だもんで、ウォームスタンバイとかもったいなくて…。

  • by Anonymous Coward on 2009年07月03日 15時48分 (#1598859)
    VACUUMが不要になったということでしょうか。
    • by Anonymous Coward on 2009年07月03日 18時59分 (#1598971)
      http://lets.postgresql.jp/documents/technical/8.4/ [postgresql.jp]

      PostgreSQL は追記型アーキテクチャを採用しており、UPDATE や DELETE の際にガベージが生じます。そのガベージを除去する処理が VACUUMです。8.3 までは VACUUM の際にテーブル全体をスキャンしてガベージを探していましたが、8.4 では Visibility Map によってガベージの位置を追跡し、ガベージのある箇所だけを選択的に処理するようになりました。VACUUM 時の負荷低下と時間短縮の効果が期待できます。極端な話、更新を行っていないテーブルに対する VACUUM では I/O は全く発生しません。 Visibility Map と HOT更新との関係が気になる方もいらっしゃるかもしれませんが、HOT は「ガベージの量を減らす」機能であり、一方 Visibility Map は「ガベージの回収を効率化する」効果を持ちます。基本的には直交した改良です。

      だそうですよ

      親コメント
      • by Anonymous Coward
        更新されているテーブルの場合に、負荷低下と時間短縮の効果は、どれくらい期待できるのでしょうか。VACUUMでどの程度の負荷があるかが定量的に示されれば分かり易いです。
      • by Anonymous Coward

        SQLiteにも似たようなauto vacuum付かないかな・・・

    • by Anonymous Coward
      "auto vacuum" 機能については 8.3 から大きな変化は無いということでしょう。
      • by Anonymous Coward
        現在のVACUUMの制約やボトルネックはどのようなのでしょう。
        • by Driver (32138) on 2009年07月04日 11時06分 (#1599214) 日記

          8.3でHOTが導入された以降、PostgreSQLを力一杯使ったことがないのでボトルネックになりそうな部分を知りませんが・・・

          以下VACUUMのテコ入れをしなくなった理由の想像を含みます。
          8.2までは、トランザクションが大量発生するような使用用途(ログ収集やチケット予約など)だと、AUTO VACUUMでも頻繁に動かさないと、無効領域が増大し続ける場合がありました。(1日の想定トランザクションを500万件以上として検証したとき)
          AUTO VACUUMでも、システムにかかる負荷は大きかったため、VACUUMが動作したとたんパフォーマンスが落ちました。
          それでも、1日のトランザクション量が数万件程度ならAUTO VACUUMの動作頻度のチューニングだけで十分運用に耐えられるのではないかと思います。

          HOTの効果で、VACUUMしなくても再利用可能な表領域が増えたため、VACUUMの動作時間が大幅に減少(多分10分の1以下、もっとかも)しているはずです。
          少なくとも私が感じていたボトルネックは無くなったのではないかと思います。

          制約の変更については把握していません。
          個人的な感覚としては「PostgreSQLはVACUUMが必要だから運用が面倒だし、使い方を考えないと自分の首を絞める」なんて印象は無くなっています。
          (少なくとも8.1までは24時間稼働するようなシステムでは使わないほうが良いと思っていた)

          ACさんはどんな懸念を持っていますか?

          親コメント
          • >HOTの効果で、VACUUMしなくても再利用可能な表領域が増えたため
            というよりゴミが出なく(少なく)なったため再利用の必要が(相対的に)低下した、のではないでしょうか。
            同じ頻度で回収してたとしたら、量が少ない分、一回の回収時間も速い。

            8.4ではさらに、全部のゴミ置き場を回るのではなく、粗大ゴミ収集のようにゴミのある置き場だけピンポイントで回るらしいのでもっと速いはず。

            親コメント
  • by Anonymous Coward on 2009年07月04日 9時52分 (#1599201)

    >ウィンドウ関数実装

    Oracleみたいにrank over partition byとかいけるんですね。嬉しい。
    素のgroup byなんてもう書く気しないよ。

    >再帰クエリの対応

    やった!と思ったけど、
    よくみたらOracle独自文法よりは簡潔さで劣る。がっかり。

    まああれだ。
    よくSQLは関数型言語みたいなもんだとかいうが、
    実際には関数型の事実上の要件である「再帰」が弱いんで激しくイマイチ。

    あと根本的に「2次元表でしかデータを返せない」ので
    2次元じゃ収まりの悪いデータ構造を扱うのが面倒!

    そんなわけで、SQL言語の高級化は、なかなか進めるのが難しいね…

    • by CowardDuck (25674) on 2009年07月04日 14時16分 (#1599275)
      > まああれだ。
      > よくSQLは関数型言語みたいなもんだとかいうが、
      > 実際には関数型の事実上の要件である「再帰」が弱いんで激しくイマイチ。
      >
      > あと根本的に「2次元表でしかデータを返せない」ので
      > 2次元じゃ収まりの悪いデータ構造を扱うのが面倒!

      いってることは正しいが、それは RDB の意図的な仕様なのであって
      欠陥ではない。

      もともとが終了判定可能な範囲で実用的な処理を行なうには
      どうすれば良いのか?というところから RDB のアプローチは
      始まっている。

      このアプローチの最大の利点は何らかの処理を実施して、それが
      なかなか終了しない場合に、その理由が無限ループや無限再起に
      陥っているのではなく性能的欠陥であるという判断がすぐに
      下せることだ。
      親コメント
      • by Anonymous Coward

        >RDB の意図的な仕様

        当初はともかく今(SQL99くらいから)は再帰SQLがありますよね。

        また、更にその改良版(と私は思っています)として、
        http://otndnld.oracle.co.jp/products/database/oracle10g/htdocs/gennick... [oracle.co.jp]
        の「ループからの脱出」というところに、
        (Oracle独自かつ10g以降の機能とはいえ)
        ループにはまる恐れがあるデータを
        検出し回避する仕組みが紹介されています。
        これで「安全に」再帰がおこなえることが保証できます。

        RDBが元々意図的に再帰できんように作られていたというなら、

  • by Anonymous Coward on 2009年07月04日 21時37分 (#1599394)
    Google Trendsによれば、世界的にはMySQLの方が10倍〜20倍の知名度 [google.com]があるのに、

    日本だけがMySQLに匹敵するくらいの知名度 [google.com]を誇っている。

    何このガラパゴスっぷりは。

    こんな世界でも希なシェアの偏りだといろいろ問題もありそうだが。
    • by shiragaoyadi (27158) on 2009年07月06日 12時43分 (#1600032)
      うちの開発は、メインがSQLServer、サブはPostgreSQLを使っています。
      MySQLを考えたのですが、販売時ライセンスを考えるとMyは売りにくい。
      Pはオールフリーで、MS-SQLからのDB乗換えの手間を考えて、Pを選択しました。
      日本での認知度だけが高いことは、選択時にかなり心配しましたが、
      その後3年間を見ても順当に開発が進んでおり、
      (逆にMyの方が今度のOracle買収で・・・・・)
      現実的に良い選択だったと、今のところ思っています。
      今後は、廉価で規模の小さい事業所への納入は、メインストリーム商品も
      Postgreを使えるように改造する計画もあります。

      他でも適応能力があり、進化が止まっているわけでもないので、
      ガラパゴスだとは思いません。
      親コメント
    • by Anonymous Coward
      >こんな世界でも希なシェアの偏りだといろいろ問題もありそうだが。

      問題、あるのかなぁ。
      思いつかない。
    • by Anonymous Coward
      一度間違って使うと捨てられなくなるというだけでしょう。 Windowsと同じで、たまたま使われてしまって、利用者が増えただけで、性能面での差はないということです。
      • by Anonymous Coward
        間違って、とかいうのは誤り。
        選ばれる理由ってのはあるのだよ、ここは英語圏じゃないんだから。

        #Windowsが選ばれたのが「たまたま」って論評もかなり珍しいな。
        #世界的にもトップシェアのものをつかまえて。
        • by Anonymous Coward
          >#世界的にもトップシェアのものをつかまえて。
          ハンバーガーがよい食物でないのと同じです。
    • by Anonymous Coward

      大昔の話になりますが、MySQL使おうと思った時に
      トランザクションが無かったか、できた直後だかで
      使えないと判断して、Postgresを選択しました。

      で、一度使ってしまうと、そうそう変える気にはなりません。
      速度を求める業務なら、別なんでしょうけど。

    • by Anonymous Coward

      普及当初SRAが一生懸命旗を振ってたからでしょう

    • by Anonymous Coward

      それを言うなら一番最初に「嘆く」べきはRubyだ。なにせ日本製。ガラパゴスの最たるもの。

      …が、嘆くよりは応援するに値するとは思うけどね>Ruby

typodupeerror

私は悩みをリストアップし始めたが、そのあまりの長さにいやけがさし、何も考えないことにした。-- Robert C. Pike

読み込み中...