Um exemplo bem prático:
Suponha uma tabela User que tenha uma coluna "excluída" que armazena carimbo de data/hora. Suponha que exista um filtro "excluído NÃO É NULO" em praticamente todas as consultas que acessam essa tabela. Este campo muito raramente não é nulo e, quando é, geralmente é de curta duração.
Perguntas:
- É necessário um índice? Embora a entropia desta coluna seja geralmente 1, não acho que o Postsgresql acompanhe a entropia sem criar um índice, o que significa que precisaria fazer uma varredura completa da tabela para cada consulta (provavelmente como a última operação, mas ainda ai!)
- Faz sentido pré-otimizar esse índice para ser um índice de hash em vez de um índice B, supondo que eu não precise de todos os operadores adicionais do índice B? Como a entropia está próxima de 1, não acho que haja uma grande diferença de tamanho entre os dois índices e, portanto, um B-Index seria superior.
Não, um índice
deletedativado não seria útil, porque a condição elimina poucas linhas para garantir uma varredura de índice.Mas se todas as suas consultas contiverem
WHERE deleted IS NOT NULL, você poderá criar todos os seus índices com a mesmaWHEREcondição. Esses “índices parciais” podem ser usados com essas consultas e excluem automaticamente as linhas que não atendem a essa condição do conjunto de resultados. Então você indexou a condição sem criar um índice extra!