Tamanho do banco de dados reduzido após backup no PostgreSQL 8.3 e restauração no PostgreSQL 9.4

Eu fiz um pg_dumpem um banco de dados JIRA que estava hospedando em um servidor PostgreSQL 8.3. O tamanho do banco de dados após vacuum fullera 217132652(aproximadamente 207 MB).

Em seguida, restaurei o banco de dados JIRA em um servidor PostgreSQL 9.4 com o seguinte comando:

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

Presumo que a restauração saia com qualquer erro desde que usei ON_ERROR_STOP=1, mas o script SQL foi concluído corretamente (apesar de alguns avisos não relacionados à restauração de dados).

Acabei com um banco de dados com um tamanho de 158019348(aproximadamente 151 MB).

Então, qual é a história aqui? Posso apenas assumir que o banco de dados foi restaurado com sucesso e o PostgreSQL otimizou seu mecanismo de armazenamento (algo entre as versões 8.3 e 9.4) e está usando o espaço com mais eficiência?

Quando você restaura um banco de dados, todas as informações estão compactadas , sem espaço vazio entre linhas (ou índices), a menos que algumas configurações específicas estejam em vigor (basicamente: FILLFACTORpara tabelas e FILLFACTORíndices ).

Por outro lado, quando seu banco de dados estiver em uso há algum tempo e você tiver compartilhado inserções, atualizações e exclusões, será exibido espaço livre não utilizado . Isso ocorre pela maneira como o PostgreSQL e o Multiversion Concurrency Control, também conhecido como MVCC, funcionam. O MVCC permite menos bloqueios, o que basicamente significa que você economiza tempo . Mas você paga um preço em termos de espaço :

1. Cada um UPDATEé equivalente a um INSERTjunto com um DELETE, com a sobrecarga (pelo menos em termos de espaço usado) associada a ambos.
2. Quando você tem várias transações em execução, e cada uma está INSERTing, UPDATEing ou DELETEing, você tem simultaneamente várias cópias de cada linha envolvida.
3. O espaço alocado para essas versões de linha não será liberado imediatamente após a confirmação e, por algum tempo, será um espaço não utilizado nos arquivos em que os dados (e índices) da tabela estão sendo armazenados.

O vácuo automático cuida desse espaço que está sendo reutilizado por padrão, ou você pode ter algum procedimento específico para a aspiração de rotina .

Esse fato já pode explicar a mudança de tamanho.

As otimizações entre versões provavelmente também ocorreram; e pode explicar outras melhorias. Otimizações também poderiam ter sido feitas para velocidade e não para tamanho, e o tamanho real poderia realmente crescer de uma versão para a seguinte. Eu realmente não sei as especificidades para poder dizer; embora o comentário do @Erwin afirme que tanto as alterações que diminuem suas tabelas quanto as que aumentam de tamanho ocorrem desde a versão 8.3.

Para distinguir entre os dois efeitos, se você estiver curioso, poderá, como sugere @Jack Douglas, restaurar seu banco de dados na versão 8.3. Provavelmente diminuirá de tamanho. Se ele diminuir para menos de 151 MB (um tamanho menor do que o obtido na versão 9.4), a remoção do espaço não utilizado fez o banco de dados diminuir e a alteração de versão realmente fez o banco de dados crescer.

Para uma melhor compreensão do MVCC, veja a apresentação de Bruce Momjian .