Qual é o nível aceitável de fragmentação do índice BTree no Postgres?

Depende™. A fragmentação por si só não é boa nem ruim, é apenas uma propriedade do índice. Se todas as suas consultas examinarem o índice em busca de um valor exclusivo, elas lerão um punhado de páginas, no máximo, em qualquer caso, portanto, não importa se o índice está fragmentado. Se, por outro lado, você digitaliza rotineiramente grandes intervalos de páginas, muitas páginas vazias provavelmente seriam prejudiciais. Você precisará examinar as estatísticas de E/S para decidir o que é aceitável.

Acho que leaf_fragmentationpode não ser uma boa indicação para nada, mas terei prazer em aprender com alguém que sabe melhor. De acordo com o código, é a porcentagem de páginas folha em que a página folha seguinte possui um número de bloco menor. Isso pode ser significativo se você digitalizar partes maiores de um índice armazenado na ferrugem giratória, mas nada mais.

Para mim, a coluna importante é avg_leaf_density. Se for muito baixo, seu índice ficará inchado e ineficiente.

A questão de quais valores são aceitáveis ​​é difícil. Eu diria que qualquer coisa acima de 30% está bem, mas 20% também não é terrível.

Se você não tiver certeza se deve reconstruir um índice ou não, pergunte-se o seguinte:

• Se você observar o inchaço ao longo do tempo, ele aumenta continuamente? Se sim, isso é ruim e REINDEXprovavelmente é necessário.

• Se o inchaço permanecer alto, mas não aumentar, REINDEXuma vez e observe

  • Isso melhora o desempenho do seu aplicativo?

  • O índice fica inchado novamente até ficar tão inchado quanto antes?

  “Não” à segunda pergunta sugeriria deixar o índice de lado.

Se você decidir REINDEX, explore se configurações de vácuo automático mais agressivas na tabela afetada podem reduzir o inchaço.