ピッキングc） あなたの質問から：
@Craigはすでに説明しています
、「TOAST可能」で特定のしきい値より大きい列は、テーブルごとに専用のTOASTテーブルにオフラインで格納されます（個別の「リレーションフォーク」、ディスク上の個別のファイル）。つまり、5MBのbytea 列自体が変更されていない場合、更新時に列はほとんど変更されません。 マニュアル：
大胆な強調鉱山。
メインリレーションフォークの行は引き続きコピーされ、更新時にデッド行が残ります（値が実際に変更されたかどうかは関係ありません）。行サイズが大きい場合は、次の解決策が役立つ可能性があります。
小さな個別の1：1テーブルを作成します 頻繁に変更されるフラグ用。主キー（=同時に外部キー）と頻繁に変更されるフラグのみ。これにより、更新が大幅に高速化され、ディスク領域が維持されます。初期の余分なオーバーヘッドと、両方のテーブルを結合する必要のあるクエリのコストが発生します（他のクエリは実際には高速になります）。テーブル行のディスク上のスペース要件の詳細：