アカウント名:
パスワード:
他のDBを推している人からすれば「vacuumなんて作業が必要になること自体に問題がある」と言われそうですが、
MySQLのInnoDBエンジンでも、更新・削除・追加を繰り返していると性能が落ちますね。 そういうときは、OPTIMIZE TABLEを行うことになりますが、これはたんにテーブルを作り直しているだけです。:)
そのうちauto vacuum的な物が入るのかもしれません。
ロールバックセグメントは、不要領域を集中管理することによってテーブル上の不要領域を意識する必要がなくなると言う反面、ロールバック時や、古いバージョンの検索のためには非常に面倒なロジックが必要になります。一方で、すべてのバージョンを平等に取り扱うPostgreSQLはシンプルで済みますが、ガベージコレクションであるvacuumが面倒になります。
PostgreSQLの不要領域管理は基本的にシンプルで、今回のHOTのような特定の頻発するケースに対する最適化は初めてじゃないでしょうかね。ようやく最適化に目が向いてきたと言うことで、例えばロールバックセグメント方式採用といった大変更の前に、まずは小さな改善を積み重ねる価値があるんじゃないかと思います。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
にわかな奴ほど語りたがる -- あるハッカー
MySQLでもvacuum必要 (スコア:3, 参考になる)
MySQLのInnoDBエンジンでも、更新・削除・追加を繰り返していると性能が落ちますね。
そういうときは、OPTIMIZE TABLEを行うことになりますが、これはたんにテーブルを作り直しているだけです。:)
そのうちauto vacuum的な物が入るのかもしれません。
Re: (スコア:0)
テーブルを作成しなおしてexpしたデータをimpしなおす事もやってたし
24h運用に致命的でなきゃvacuumもあってもいいかな。
#最近Oracle使う仕事は他人に振ったので最近の事情は知らない
Re: (スコア:4, 参考になる)
PostgreSQL はマルチバージョニング(トランザクション開始時点の状態のデータにアクセスするための機構)を
実現するために
「内部では更新の度に新規レコードを作っている」
のです。そしてこれを解放する必要が生じするのです。(約2億レコードに達する前に?)
ですから、
「Vacuum に相当する機構を行わないOracle」というものは
「ロールバックセグメントがいつまでも膨れ続けるOracle」
と考えればいいのではないでしょうか?
MySQL のことはわかりません。
# 勘違いだったらやなので AC
マクロの基本は検索置換(by y.mikome)
Re: (スコア:1)
エクステンション書き出し前の一時領域だし
vacuumの不要領域との比較はあんまり意味無いかも。
Oracleは不要領域を再利用してもデータ領域の断片化に対して
今のところは上手くアプローチ出来ているんじゃない?って思う。
逆にvacuumで何とかしようってアプローチが限界が来ているんじゃないかな?
Re:MySQLでもvacuum必要 (スコア:5, 参考になる)
ロールバックセグメントは、不要領域を集中管理することによってテーブル上の不要領域を意識する必要がなくなると言う反面、ロールバック時や、古いバージョンの検索のためには非常に面倒なロジックが必要になります。一方で、すべてのバージョンを平等に取り扱うPostgreSQLはシンプルで済みますが、ガベージコレクションであるvacuumが面倒になります。
PostgreSQLの不要領域管理は基本的にシンプルで、今回のHOTのような特定の頻発するケースに対する最適化は初めてじゃないでしょうかね。ようやく最適化に目が向いてきたと言うことで、例えばロールバックセグメント方式採用といった大変更の前に、まずは小さな改善を積み重ねる価値があるんじゃないかと思います。