Excluí ~ 65 milhões de linhas de uma tabela PostgreSQL com ~ 75 milhões de linhas. Assim que a consulta de exclusão foi concluída, a CPU caiu para 100% por cerca de cinco minutos.
A tabela da qual as linhas foram excluídas tem vários índices e estava em uso intenso durante a exclusão e depois dela. Infelizmente não tenho como reproduzir isso, pois aconteceu em ambiente de produção.
É provável que o autovacuum tenha entrado em ação e, em caso afirmativo, poderia conduzir um banco de dados com 32 núcleos de CPU para 100% de uso da CPU? Em caso afirmativo, existe uma maneira de limitar a ingestão de autovacuum para que não prejudique o desempenho do banco de dados após consultas de exclusão em massa?
Estou usando o PostgreSQL versão 14.8.
Isso soa como um problema que encontrei antes (ou alguma variação dele), mas sem acesso aos seus servidores ou a capacidade de reproduzi-lo, não tenho certeza.
Se você tiver muitas consultas que selecionam o valor mínimo/máximo de uma coluna indexada nessa tabela, elas normalmente serão atendidas instantaneamente consultando os pontos finais do índice. Mas quando muitas linhas no final foram excluídas, ele precisa voltar até encontrar o ponto extremo que ainda está ativo. Isso pode demorar um pouco quando você tiver tantas linhas excluídas que precisam ser passadas. Uma vez que as tuplas excluídas estejam "mortas para todos" (todas as transações abertas no momento do DELETE foram embora), você deve ser capaz de definir bits de dica nas próprias tuplas e nas entradas de índice ('microvacuum' ou 'itens mortos' ou 'bits de dica de índice') que resolvem ou pelo menos melhoram o problema e, finalmente, devem ser completamente resolvidos pelo vácuo, que deve remover não apenas as entradas do índice, mas também páginas de índice que estão cheias de nada além de entradas mortas. Mas até que todas as transações/instantâneos de vida longa desapareçam, nenhum desses mecanismos funcionará, portanto, certifique-se de não ter transações abertas.
Em resumo, o autovacuum não está causando o problema. Em vez disso, ele está tentando corrigir o problema e ainda não terminou ou foi frustrado por instantâneos abertos.
Na versão mais antiga, a mesma coisa pode acontecer ao fazer estimativas de custo para mergejoins. O processo de planejamento fez o mesmo tipo de sondagem de ponto final e sofreu o mesmo problema. Eu acho que esse problema foi corrigido pela v14, no entanto.