Vou usar um índice BRIN para substituir o índice B-tree em uma coluna de data/hora no Postgresql-11. Eu nunca usei antes.
Já que um índice BRIN pode ser mais eficaz se os dados forem armazenados fisicamente na ordem em que a coluna está sendo indexada.
Estou em dúvida se devo ou não excluir todos os dados, e depois reinseri-los no pedido. Meus dados estão sendo usados para análise estática, não mudariam.
Como tudo relacionado a bancos de dados, a resposta será “depende”.
Os índices BRIN são eficientes se a ordenação dos valores-chave seguir a organização dos blocos na camada de armazenamento. No caso mais simples, isso pode exigir a ordenação física da tabela, que geralmente é a ordem de criação das linhas dentro dela, para corresponder à ordem das chaves. Chaves em números de sequência gerados ou dados criados são os melhores candidatos para um índice BRIN.
Você mencionou que o índice será feito em uma coluna de data/hora, portanto, desde que esses registros já estejam armazenados sequencialmente na tabela, você não precisará fazer um dump e recarregar. Se os valores estiverem em todos os lugares, seria de seu interesse exportar os dados na nova ordem, descartar a tabela e recarregar.
Os índices BRIN usam muito menos armazenamento em comparação com um índice B-Tree normal, mas podem ser bastante “com perdas”, o que reduzirá sua eficácia. Você pode ajustar isso especificando um
pages_per_range
valor como este:Os índices BRIN armazenam entradas para um intervalo de páginas em uma tabela correspondente. Quanto maior o intervalo de páginas, menor o índice. Quanto menor o índice, mais perdedor ele se torna.
Como os índices podem ser criados e destruídos muito mais rapidamente do que um carregamento de tabela completo (névoa do tempo), sugiro brincar em um sistema de não produção para ver se um BRIN é melhor que uma árvore B para seu caso de uso e se os dados da sua tabela forem sequenciais o suficiente para não exigir um recarregamento.
Espero ter ajudado ??