O cancelamento de um processo (AUTO) VACUUM no PostgreSQL torna todo o trabalho inútil?


13

Em algumas ocasiões, e depois de fazer um maciço update, insertou deletea partir de uma mesa, eu comecei um VACUUM FULL ANALYZEpara garantir que a DB não estava sendo muito inchado. Fazer isso em um banco de dados de produção me permitiu descobrir que não era uma boa ideia, porque eu poderia bloquear a tabela por um longo período de tempo. Então, cancelei o processo, talvez tentei apenas VACUUM(não completo) ou deixei AUTOVACUUMfazer mais tarde o que puder.

A pergunta é: se eu interromper um VACUUM ou AUTOVACUUM "no meio do caminho", todo o processamento já está perdido?

Por exemplo, se você VACUUMjá encontrou 1 milhão de linhas mortas e eu paro, todas essas informações são perdidas? O VACUUM funciona de maneira totalmente transacional ("tudo ou nada", como um número muito bom de processos do PostgreSQL)?

Se o VACUUM puder ser interrompido com segurança sem que todo o trabalho seja perdido, existe alguma maneira de fazer o vacuumtrabalho de forma incremental? [Trabalhe por 100 ms, pare, aguarde 10 ms para permitir o bloqueio do resto do mundo ... e assim por diante]. Eu sei que você pode fazer parte disso ajustando os parâmetros de vácuo automático, mas estou pensando na possibilidade de controlar isso programaticamente, de fazê-lo em determinados momentos / sob certas condições.


NOTA: Parar / cancelar / eliminar o processo significa neste contexto:

  • Se estiver usando o pgAdmin, pressione o botão "Cancelar consulta".
  • Se estiver trabalhando programaticamente, chame pg_cancel_backend ().

Presumo que ambos sejam equivalentes. Eu não usei nenhum comando kill / shell no nível do sistema.

Respostas:


8

O trabalho realizado por um VACUUM FULL interrompido será totalmente perdido, pois ele simplesmente reverterá para o uso da versão anterior da tabela e descartará a versão em andamento da tabela.

O trabalho realizado por um VACUUM regular (não COMPLETO) pode não ser totalmente perdido. Ele limpa os índices em lotes, e todos os lotes que foram totalmente limpos não precisarão ser limpos novamente. Eles ainda precisarão ser inspecionados novamente, mas serão encontrados já limpos na próxima vez. Portanto, você pode salvar algumas E / S de gravação que não precisarão ser repetidas.


11
Gostaria muito de mais detalhes sobre isso, especialmente no autovacuum. Eu tenho servidores ocupados com muitos bancos de dados e, às vezes, os autovacuums podem levar muito tempo. Quando isso acontece, a criação de um novo índice, por exemplo, é impossível porque o vácuo automático possui um bloqueio. Em alguns casos, seria ideal eliminar o vácuo automático e aplicar o índice e, esperançosamente, quando o vácuo automático for executado novamente, ele não precisará ser executado por quase tanto tempo. Alguma maneira de ver detalhes do que o autovacuum fez / está fazendo em uma tabela e índices?
Kurt Koller

3
9.6 introduziu uma visão para monitorar o progresso do vácuo: postgresql.org/docs/current/static/progress-reporting.html . Eu não brinquei com isso sozinho, então não sei como isso funcionará para você. O vácuo automático deve ceder automaticamente à trava, a menos que esteja sendo feito para contornar. As configurações padrão do autovacuum são fortemente aceleradas, portanto, pode não ser mais rápido na próxima vez, apenas porque está sendo acelerada na mesma velocidade. Eu rotineiramente defino vacuum_cost_page_hite vacuum_cost_page_misspara zero.
jjanes
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.