Comentários Sobre Indexação...

Seguem respostas, ao menos as que posso dar hoje, aos comentários do Telles. Você também pode postar os seus!

"Opa, muito bacana esta série sobre índices... este é um assunto que dá pano para manga! Algumas sugestões para explorar mais o
* Seria interessante fazer um EXPLAIN num SELECT de uma grande tabela para comparar o ganho de velocidade e volume em disco de diferentes valores de FILLFACTOR;"

Com certeza esse seria um bom teste a ser feito. Bom, fica na minha fila de coisas a fazer. Como esta lista cresce rápido...

"* Exemplificar o uso da cláusula CONCURRENTLY;"

A cláusula CONCURRENTLY aparece em um dos nossos exemplos, no entanto o texto explicando seu funcionamento pode ser melhorado.

O uso de CONCURRENTLY faz com que o banco de dados ignore que se está fazendo inserções, atualizações e exclusões durante a sua criação, fazendo com que a construção do índice seja mais rápida. No entanto impede que a criação do índice seja feita dentro de uma transação e o índice criado pode não estar 100% correto, em virtude das alterações concorrentes relaizadas durante sua criaçao, demandando um comando REINDEX.

Só utilize esta cláusula se lidares com grandes massas de dados em um sistema em que a performance seja crítica.

"* Apontar quando a utilização de um determinado índice é melhor (B-TREE, HASH, GIST e GIN);"

Nossa, devia ter comentado isso mesmo!
No PostgreSQL, a indexação pode utilizar recursos que reduzam a portabilidade. Caso o mesmo esquema de banco seja utilizado em vários outros SGBDs devem ser ignorados os índices GIST e GIN. Os índices HASH e BTREE têm implementação mais difundida em outras plataformas.

Sugestão:

BTREE - utilizar como padrão. Flexível e com bom custo benefício.

HASH - Utilizar apenas quando as consultas utilizando o operador de igualdade como condicional "=" estiverem lentas, caso não se precise logar a operação, pois operações com HASH não são armazenadas no log do PostgreSQL. O usuário deve lembrar que a reconstrução do índice em caso de falha deve ser disparada manualmente.
A rapidez do HASH é maior que a da árvore B, mas o memso demanda mais manutenção.

GIST - É um "índice programável" para tipos definidos pelo usuário. Não usar caso se deseje compatibilidade com outro banco. Também ainda é um recurso pouco empregado da ferramenta, a não ser que você instale algum módulo extra, que pode utilizá-lo sem que sequer saibamos.
Não consegui fazer funcionar nos meus testes. Acho que é questão de tempo. Aí eu faço um post só para o GIST.

GIN - É um índice muito recentemente adicionado ao banco, voltado para para tipos de dados em que uma chave ocorra mais de uma vez no banco de dados. Não usar caso se deseje compatibilidade com outro SGBD. Também ainda é um recurso pouco empregado da ferramenta, ainda mais por ser relativamente recente.
Achei difícil de utilizar e não consegui fazer funcionar nos meus testes. Acho que é questão de tempo. Aí eu faço um post só para o GIN. Alguém já está usando GIN?

ÍNDICES PARCIAIS - Fáceis de usar e úteis para otimizar certas consultas. Não usar caso se deseje manter compatibilidade para outros bancos.

"* Como criar índices que retornem a correta ordenação para pt_BR utilizando o OPERATOR CLASS;"

Ainda estou estudando isso. Está na minha lista, mas bem atrás.
Alguém conhece algum texto bom a respeito?

"Além disso, seria interessante utilizar uma nomeação para os índices mais consistentes, criar nomes como ind1, ind2 e ind3 não costuma ser muito recomendado."

MEA CULPA!!! Para os próximos exemplos pretendo utilizar NOMEOBJETOINDEXADO_SUFIXO. Minha dúvida é se compensa rever o post e alterar os exemplos...
Alguém sugere uma nomenclatura alternativa?

"Fica aí o desafio... o que você acha? Por último deixo aqui a recomendação de uma apresentação interesante do Sr. Josh Berkus chamada The Joy Of Index que é bem interessante."

Esse texto é realmente MUITO instrutivo.
Nele são detalhados alguns importantes sobre a indexação do PostgreSQL.
Com certeza vou reler mais de uma vez!