1

列と制約のあるテーブルがあります。

height smallint,
length smallint,
diameter smallint,
volume integer,
idsensorfragments integer,
CONSTRAINT sensorstats_idsensorfragments_fkey FOREIGN KEY (idsensorfragments)
  REFERENCES sensorfragments (idsensorfragments) MATCH SIMPLE
  ON UPDATE CASCADE ON DELETE CASCADE

（主キーなし）。現在、28 978 112のレコードがありますが、私の意見では、テーブルのサイズが大きすぎます。

クエリの結果：

select pg_size_pretty(pg_total_relation_size('sensorstats')), pg_size_pretty(pg_relation_size('sensorstats'))

は：

"1849 MB";"1226 MB"

idsensorfragments列にはインデックスが1つだけあります。簡単な計算を使用すると、1つのレコードに約66,7 B（？！？！）かかることがわかります。この番号がどこから来たのか誰か説明してもらえますか？

5列=2+ 2 + 2 + 4 + 4=14バイト。インデックスが1つあり、主キーはありません。レコードごとに追加の50Bはどこから来るのですか？

PSテーブルは真空にされ、分析され、インデックスが再作成されました。

4

2 に答える 2

2

特にページレイアウトで、データベース物理ストレージがどのように構成されているかを確認する必要があります。

PostgreSQLは、タプル（行）ごとおよびページごとに多数の追加フィールドを保持します。ページはデータベースが操作するアイテムであり、通常は8192バイトのサイズであるため、タプルはページに保持されます。したがって、余分なスペースの使用量は次のようになります。

  • PageHeader、24バイト;
  • タプルヘッダー、27バイト;
  • 「見えない」タプルバージョン。
  • テーブルのストレージパラメータに従って、予約済みの空き領域。
  • NULLインジケーター配列;
  • （もっと何かを逃したかもしれません）。

物理ストレージのレイアウトはメジャーリリース間で変更されるため、完全なダンプ/復元を実行する必要があります。最近のバージョンpg_upgradeでは、このプロセスで非常に役立ちます。

于 2012-07-03T08:53:23.777 に答える
0

VACUUM FULLまたはCLUSTERを実行しましたか？そうでない場合でも、未使用のスペースはこのテーブルとインデックス専用です。これらのステートメントはテーブルを書き換えますが、FULLのないVACUUMは書き換えを行いません。

于 2012-07-03T08:17:33.713 に答える