Respostas:
Devido à forma como o PostgreSQL lida com transações e simultaneidade, o MVCC - Controle de Concorrência em várias Versões, você pode ficar inchado. No PostgreSQL, quando você faz um UPDATEou DELETE, a linha não é realmente excluída fisicamente. Para a DELETE, simplesmente marca a linha como indisponível para transações futuras e UPDATE, sob o capô, é uma combinação INSERTentão DELETE, em que a versão anterior da linha é marcada como indisponível.
Enquanto os dados estão marcados como indisponíveis, eles ainda estão lá e o espaço não pode ser usado. Para marcar o espaço como disponível para uso pelo banco de dados, é necessário um processo de vácuo por trás das operações e marcar esse espaço disponível para o banco de dados usar. No entanto, ele não é retornado ao sistema operacional. Isso acontece apenas quando não há linhas ativas em uma página inteira, o que pode ser incomum em algumas cargas de trabalho. Isso pode ser bom para algumas cargas de trabalho, porque você pode simplesmente atualizar o espaço nas páginas individuais dentro dos arquivos de dados, sem precisar adicionar arquivos de dados adicionais.
Os problemas surgem com inchaço quando há um número excessivamente grande de tuplas mortas versus tuplas vivas. Caminhar e verificar todos os sinalizadores de visibilidade leva tempo e ter mais arquivos de dados para uma relação resulta em carga de E / S desnecessária. O inchaço é especialmente visível nos índices, que também podem ter muitas tuplas mortas, às vezes muito mais do que a tabela. O Bloat pode atrasar pesquisas e verificações de índice, que serão exibidas aumentando lentamente o tempo de consulta e alterando os planos de consulta.
Você pode restaurar o espaço usando pg_reorg , pg_repack , CLUSTERou VACUUM FULL. Isso examinará e reorganizará os arquivos, movendo tuplas e reorganizando para garantir que não haja tuplas mortas, o que eliminará o inchaço.
O Bloat também pode ser gerenciado com eficiência, ajustando as VACUUMconfigurações por tabela, que marca o espaço morto da tupla disponível para reutilização em consultas subsequentes.
Você pode usar consultas no Wiki do PostgreSQL relacionadas a Show Database Bloat e Index Bloat para determinar quanto inchaço você tem e, a partir daí, faça uma análise de desempenho para verificar se você tem problemas com a quantidade de inchaço existente em suas tabelas. .
Provavelmente, isso se refere a problemas comuns com índices nos quais duas colunas são adicionadas ao índice ou há índices sobrepostos em uma tabela. Ou seja, vários índices com o mesmo conjunto de colunas neles (tornando um deles desnecessário). Gostaria de revisar todos os índices em tabelas procurando colunas sobrepostas, procurando índices que são apenas subconjuntos de outros índices e removê-los SE você puder determinar que eles não estão sendo usados.
Além disso, à medida que os dados nas tabelas são atualizados, os índices podem se fragmentar, o que os torna maiores do que o necessário. Não estou familiarizado com o postgres, mas suspeito que existem métodos para desfragmentar os índices (reconstruindo os índices) que reduzirão seu tamanho no disco.