PostgreSQL 8.3でのバックアップおよびPostgreSQL 9.4での復元後にデータベースサイズが縮小

私は、pg_dumpPostgreSQL 8.3サーバーでホストしているJIRAデータベースで実行しました。データベース後のサイズvacuum fullだった217132652（約207メガバイト）。

次に、次のコマンドを使用して、JIRAデータベースをPostgreSQL 9.4サーバーに復元しました。

$ psql -X -v ON_ERROR_STOP=1 -d jira2 -U jira -h localhost < jiradb2017_03_12.sql

私はを使用して以来、エラーが発生すると復元が終了すると思いON_ERROR_STOP=1ますが、SQLスクリプトは正常に終了しました（データの復元に関連しないいくつかの警告にもかかわらず）。

最終的に、サイズが158019348（約151 MB）のデータベースができました。

だから、ここの話は何ですか？データベースが正常に復元され、PostgreSQLがストレージ（バージョン8.3から9.4の間）を最適化し、スペースをより効率的に使用していると仮定できますか？

データベースを復元すると、特定の設定（基本的に：テーブルとインデックス）が設定されていない限り、行間（またはインデックス内）に空のスペースがなく、すべての情報がパックされています。FILLFACTORFILLFACTOR

一方、データベースがしばらく使用されていて、挿入、更新、削除を共有している場合は、未使用の空き領域が表示されます。これは、PostgreSQLおよびMultiversion Concurrency Control（別名MVCC）の動作方法が原因です。MVCCはより少ないロックを可能にします。つまり、基本的に時間を節約し ます。しかし、あなたはスペースの面で代価を支払います：

1. Every UPDATEは、とをINSERT組み合わせたものに相当DELETEし、オーバーヘッドは（少なくとも使用されるスペースに関して）両方に関連付けられています。
2. 複数のトランザクションを実行していて、すべてがINSERTing、UPDATEing、またはDELETEingである場合、関係するすべての行の複数のコピーが同時に存在します。
3. これらの行バージョンに割り当てられたスペースは、コミット後すぐには解放されず、しばらくの間、テーブルデータ（およびインデックス）が格納されているファイル内の未使用スペースになります。

Autovacuumは、このスペースがデフォルトで再利用可能になるように処理します。または、ルーチンの掃除のための特定の手順を用意することもできます。

この事実はすでにサイズの変化を説明することができます。

バージョン間の最適化もおそらく行われました。さらに改善を説明できます。サイズではなく速度を最適化することもでき、実際のサイズは実際にバージョンごとに大きくなる可能性があります。具体的には、具体的にはわかりません。ただし、@ Erwinからのコメントでは、テーブルを縮小する変更とテーブルを肥大化（拡張）する変更の両方がバージョン8.3以降行われたと述べています。

2つの効果を区別するために、もし興味があれば、@ Jack Douglasが示唆するように、データベースを8.3に復元することができます。それはおそらくサイズが縮小します。それが151 MB（9.4バージョンよりも小さいサイズ）に縮小した場合、未使用のスペースを削除するとDBが縮小し、バージョンの変更により実際にDBが拡大しました。

MVCCの理解を深めるには、Bruce Momjianのプレゼンテーションをご覧ください。