3

ディスク上のサイズを 2 倍にせずに、非 null 型の列を Postgresql テーブルに追加する方法はありますか? たとえば、いくつかの列が定義されたテーブルがあり、列を追加したい場合は、次のようにします。 

alter table my_table add new_column int  
update table my_table set new_column = 0 
alter table my_table alter column new_column set not null

これにより、Postgresql の動作により、テーブルに割り当てられるスペースが事実上 2 倍になります。更新により、このトランザクションが終了し、vacuum がジョブを実行した後に再利用するようにマークされる新しいタプルが作成されます。テーブルのサイズが大きい (つまり、数百万行) が、非常にゆっくりと成長するか、サイズがほぼ一定である場合、それらの行は再利用されず、「完全なバキューム」または完全なデータベースのバックアップと復元のみがディスク上のスペースを再利用します。デフォルト値を持つ列を自動的に追加する方法はありますが、この動作はありませんか? たとえば、テーブルをロックして更新を行う方法があれば、この場合 MVCC は必要ありません。

4

2 に答える 2

4

次の手順で行います。

  1. テーブルの変更 新しい列の追加
  2. テーブルの変更 列のデフォルト値の追加
  3. 更新しますが、1 つの更新ステートメントでテーブル全体ではありませんが、それぞれ独自のトランザクションで 10000 回の個別の更新で発行します
  4. 数百回の更新ごとにバキュームを実行するか、それ以上 - autovacuum
  5. NULL でないテーブル セットの変更
于 2010-01-18T16:32:46.237 に答える
0

テーブルのサイズが大きい (つまり、数百万行) が、非常にゆっくりと成長するか、サイズがほぼ一定である場合、それらの行は再利用されず、「完全なバキューム」または完全なデータベースのバックアップと復元のみがディスク上のスペースを再利用します。

それは怪しいようです。空き領域マップが十分に大きくないのではないかと思います。そうなると、postgres は削除された行の追跡を失い始め、vacuum full 以外では再利用できません。Postgres <= 8.3 を実行している場合、max_fsm_pages が削除された行を追跡するのに十分な大きさであることを確認しましたか? これを確認するには、テーブルに再利用されていない無効な行があるこの状態に到達するために必要なことは何でも行ってから、「vacuum full verbose」を実行します。Postgres は、vacuum の終了時に fsm の問題について通知します。

max_fsm_pages は Postgresql 8.4 で廃止されました。8.4 を実行している場合は、気にしないでください。

于 2010-01-19T06:23:24.037 に答える