「PostgreSQL 8.0 リリース」記事へのコメント

個人的には

[mikanjapan (23786)]

部分ロールバックも嬉しいが、とにかくVACUUMレスにして欲しい。
あとインデックスを含んだpg_restoreの高速化とか…無理か。

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

Re:個人的には

[bytes (17046)]

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

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

Re:個人的には

[Anonymous Coward]

MVCCっていうのは、FirebirdでいうMulti-Generational Architectureとは違うんでしょうかね? トランザクション別に違うバージョンを持つことができるということなら、同じような気がするんだけど。

で、FirebirdにはVACUUMがないのですね。

Re:個人的には

[bytes (17046)]

書き方が悪かったですね。Firebird についてはよく知りませんが、マルチバージョニングなデータベースであるという点は、確かにおっしゃる通り PostgreSQL に限らず昨今の RDBMS ならば当たり前の機能だと思います。

ただしその実装アーキテクチャが異なる、というところがこの場合の肝で、追記型の PostgreSQL 以外はほとんどの場合専用のロールバック領域 (UNDO セグメントと言ったりいろいろ) を持つのではないでしょうか。少なくとも Oracle と MySQL(InnoDB) はそうです。それらの DB では VACUUM がいらない代わりに、その専用領域の管理が必要となりま

ガベージコレクション

[Anonymous Coward]

Firebirdのガベージコレクションについては以下に説明がありましたが、とりあえず更新があったら新しいコピーを作り、後で不要になったものを回収するようになっている模様です。
PostgreSQLのVACUUMを自動でやっている感じでしょうか?

Re:ガベージコレクション

[bytes (17046)]

なるほど。貴重な情報ありがとうございます。Firebird も PostgreSQL と同じく追記型＋vacuum (garbage collection) なのですね。

ただ PostgreSQL が手動 vacuum がデフォルトなのに対して、Firebird は自動 vacuum がデフォルトらしい、という点が違うのかな。PostgreSQL も今では、データファイルのゴミ領域の割合や CPU 利用率などを鑑みながらの自動 vacuum ができるようになっていますし (もちろんちゃんと設定すれば、ですが…)、Firebird も自動 garbage collection を off にすることができるみたいですので、運用時検討項目としては同じようなものなのかも。