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が混在してる・・・ (スコア:2, 興味深い)
Re: (スコア:0)
その位なら別に難しくはあるまい？
#ま、設定ファイルで変更可であったら‥という希望は分かるが。
日本語の詳しい記事 (スコア:1, 参考になる)
新機能解説 [postgresql.jp]
# 8.3のときは自動で型キャストしなくなったと聞いて見送ったのですが、8.4はどうでしょうか
Re:日本語の詳しい記事 (スコア:1, 参考になる)
8.3 と同様みたいですね。
代わり(？)に、CAST 定義用の 構文が簡単になった [postgresql.jp] とのこと。
なにげに地味な (スコア:1)
が個人的には一番インパクトあるかも。
あと3ヶ月早ければ・・・・orz
# でも苦労したからタレコミの内容がわかるようになっててちょっと嬉しい。
8.4リリースはめでたいのだが (スコア:1)
ホットスタンバイと同期レプリケーションが 8.5 へ繰り延べになった
ことが残念でならない（PostgreSQL 8.4 の新機能 — Let's Postgres [postgresql.jp]）。
貧乏性だもんで、ウォームスタンバイとかもったいなくて…。
auto vacuum以外のテコ入れ？ (スコア:0)
Re:auto vacuum以外のテコ入れ？ (スコア:2, 参考になる)
だそうですよ
Re: (スコア:0)
Re: (スコア:0)
SQLiteにも似たようなauto vacuum付かないかな・・・
Re: (スコア:0)
Re: (スコア:0)
Re:auto vacuum以外のテコ入れ？ (スコア:2, 参考になる)
8.3でHOTが導入された以降、PostgreSQLを力一杯使ったことがないのでボトルネックになりそうな部分を知りませんが・・・
以下VACUUMのテコ入れをしなくなった理由の想像を含みます。
8.2までは、トランザクションが大量発生するような使用用途（ログ収集やチケット予約など）だと、AUTO VACUUMでも頻繁に動かさないと、無効領域が増大し続ける場合がありました。（1日の想定トランザクションを500万件以上として検証したとき）
AUTO VACUUMでも、システムにかかる負荷は大きかったため、VACUUMが動作したとたんパフォーマンスが落ちました。
それでも、１日のトランザクション量が数万件程度ならAUTO VACUUMの動作頻度のチューニングだけで十分運用に耐えられるのではないかと思います。
HOTの効果で、VACUUMしなくても再利用可能な表領域が増えたため、VACUUMの動作時間が大幅に減少（多分１０分の１以下、もっとかも）しているはずです。
少なくとも私が感じていたボトルネックは無くなったのではないかと思います。
制約の変更については把握していません。
個人的な感覚としては「PostgreSQLはVACUUMが必要だから運用が面倒だし、使い方を考えないと自分の首を絞める」なんて印象は無くなっています。
（少なくとも8.1までは24時間稼働するようなシステムでは使わないほうが良いと思っていた）
ACさんはどんな懸念を持っていますか？
Re:auto vacuum以外のテコ入れ？ (スコア:1)
>HOTの効果で、VACUUMしなくても再利用可能な表領域が増えたため
というよりゴミが出なく（少なく）なったため再利用の必要が（相対的に）低下した、のではないでしょうか。
同じ頻度で回収してたとしたら、量が少ない分、一回の回収時間も速い。
8.4ではさらに、全部のゴミ置き場を回るのではなく、粗大ゴミ収集のようにゴミのある置き場だけピンポイントで回るらしいのでもっと速いはず。
言語の高級化 (スコア:0)
>ウィンドウ関数実装
Oracleみたいにrank over partition byとかいけるんですね。嬉しい。
素のgroup byなんてもう書く気しないよ。
>再帰クエリの対応
やった！と思ったけど、
よくみたらOracle独自文法よりは簡潔さで劣る。がっかり。
まああれだ。
よくSQLは関数型言語みたいなもんだとかいうが、
実際には関数型の事実上の要件である「再帰」が弱いんで激しくイマイチ。
あと根本的に「2次元表でしかデータを返せない」ので
2次元じゃ収まりの悪いデータ構造を扱うのが面倒！
そんなわけで、SQL言語の高級化は、なかなか進めるのが難しいね…
Re:言語の高級化 (スコア:2)
> よくSQLは関数型言語みたいなもんだとかいうが、
> 実際には関数型の事実上の要件である「再帰」が弱いんで激しくイマイチ。
>
> あと根本的に「2次元表でしかデータを返せない」ので
> 2次元じゃ収まりの悪いデータ構造を扱うのが面倒！
いってることは正しいが、それは RDB の意図的な仕様なのであって
欠陥ではない。
もともとが終了判定可能な範囲で実用的な処理を行なうには
どうすれば良いのか？というところから RDB のアプローチは
始まっている。
このアプローチの最大の利点は何らかの処理を実施して、それが
なかなか終了しない場合に、その理由が無限ループや無限再起に
陥っているのではなく性能的欠陥であるという判断がすぐに
下せることだ。
Re: (スコア:0)
>RDB の意図的な仕様
当初はともかく今(SQL99くらいから)は再帰SQLがありますよね。
また、更にその改良版(と私は思っています)として、
http://otndnld.oracle.co.jp/products/database/oracle10g/htdocs/gennick... [oracle.co.jp]
の「ループからの脱出」というところに、
(Oracle独自かつ10g以降の機能とはいえ)
ループにはまる恐れがあるデータを
検出し回避する仕組みが紹介されています。
これで「安全に」再帰がおこなえることが保証できます。
RDBが元々意図的に再帰できんように作られていたというなら、
上
ガラパゴスSQL？ (スコア:0)
日本だけがMySQLに匹敵するくらいの知名度 [google.com]を誇っている。
何このガラパゴスっぷりは。
こんな世界でも希なシェアの偏りだといろいろ問題もありそうだが。
Re:ガラパゴスSQL？ (スコア:2)
MySQLを考えたのですが、販売時ライセンスを考えるとMyは売りにくい。
Pはオールフリーで、MS-SQLからのDB乗換えの手間を考えて、Pを選択しました。
日本での認知度だけが高いことは、選択時にかなり心配しましたが、
その後3年間を見ても順当に開発が進んでおり、
(逆にMyの方が今度のOracle買収で・・・・・)
現実的に良い選択だったと、今のところ思っています。
今後は、廉価で規模の小さい事業所への納入は、メインストリーム商品も
Postgreを使えるように改造する計画もあります。
他でも適応能力があり、進化が止まっているわけでもないので、
ガラパゴスだとは思いません。
Re: (スコア:0)
問題、あるのかなぁ。
思いつかない。
Re: (スコア:0)
Re: (スコア:0)
選ばれる理由ってのはあるのだよ、ここは英語圏じゃないんだから。
#Windowsが選ばれたのが「たまたま」って論評もかなり珍しいな。
#世界的にもトップシェアのものをつかまえて。
Re: (スコア:0)
ハンバーガーがよい食物でないのと同じです。
Re: (スコア:0)
大昔の話になりますが、MySQL使おうと思った時に
トランザクションが無かったか、できた直後だかで
使えないと判断して、Postgresを選択しました。
で、一度使ってしまうと、そうそう変える気にはなりません。
速度を求める業務なら、別なんでしょうけど。
Re: (スコア:0)
普及当初SRAが一生懸命旗を振ってたからでしょう
Re: (スコア:0)
それを言うなら一番最初に「嘆く」べきはRubyだ。なにせ日本製。ガラパゴスの最たるもの。
…が、嘆くよりは応援するに値するとは思うけどね＞Ruby