Gostaria de saber qual a diferença entre CREATE INDEX e CREATE INDEX CONCURRENTLY (se houver) após a criação do índice ter sido construído. Tenho discutido com um colega sobre como eles funcionam.
Meu entendimento é que CREATE INDEX exige um bloqueio completo na tabela para construir o índice rapidamente, causando tempo de inatividade, mas para CREATE INDEX CONCURRENTLY apenas um bloqueio parcial é obtido na tabela. Isso significa que os índices são calculados para cada nova transação/inserção à medida que a tabela contém gravações e, sempre que não há transações/inserções acontecendo, ela está "preenchendo" ou processando os índices para os dados que já estavam lá. Depois que esse processo de "preenchimento" for concluído, não haverá diferença estrita entre CREATE INDEX e CREATE INDEX CONCURRENTLY.
O entendimento do meu colega é que CREATE INDEX CONCURRENTLY se comporta de maneira diferente e que, mesmo após a conclusão do "processo de preenchimento", CREATE INDEX CONCURRENTLY continua sendo menos intensivo em carga nas gravações.
Alguém pode nos fornecer uma visão melhor de como funciona a criação de índices? Quando podemos dizer que um índice foi criado? O que acontece depois que o índice termina de ser criado sempre que você insere dados? E se há diferença no cálculo do índice após a conclusão da construção ao usar CONCURRENTEMENTE ou não?
A diferença está apenas na forma como os índices são construídos, mas feito isso, os resultados são os mesmos. Um índice criado simultaneamente pode ter algum inchaço, mas essa diferença diminuirá depois de um tempo.
A diferença está em “como funciona”. É sobre "Quanto tempo?" e "Podemos bloquear as alterações da tabela indexada durante o tempo de indexação?". Os resultados são os mesmos.
Qualquer um
CREATE INDEXdeve verificar sua tabela, classificar os valores do campo de destino e armazenar o resultado.O normal BLOQUEIA a mesa. Isso significa que nenhuma consulta INSERT, UPDATE ou DELETE pode ser processada até que a criação do índice seja concluída. Em Produção, dependendo da quantidade de dados, pode demorar muito . As consultas de alteração podem atingir o tempo limite e um serviço pode ficar parcialmente inoperante. Consultas SELECT funcionam normalmente com este bloqueio. Mas a partir do tempo total de processamento do banco de dados, tal solicitação será ideal e rápida. É necessária apenas uma varredura completa e classificação da tabela.
O CONCORRENTE não faz LOCK. Portanto, quaisquer atualizações podem fluir para a tabela. As consultas de mudança fluirão conforme o esperado. Mas a indexação levará muito mais tempo. Esta operação exigirá pelo menos 2 varreduras completas da tabela e classificação. Se durante a operação houve alterações - atualize os novos dados do índice e verifique novamente. Esta etapa pode ser iterada várias vezes. Portanto, sua execução não é ideal e consome muito mais tempo e recursos do que a base.
Espero que isso ajude.