Suponha que eu tenha uma tabela somente de acréscimo com colunas customer_id(string gerada aleatoriamente) e x, e as pesquisas são sempre feitas em customer_id.
Digamos que os dados se pareçam abaixo, como se tivéssemos um lote de linhas quando um cliente se inscreve para algo inicialmente e nunca mais para esse cliente.
customer_id=XCVFY0001, x=...
customer_id=XCVFY0001, x=...
(continues for ~1 page with same customer_id)
customer_id=HUMBN0001, x=...
customer_id=HUMBN0001, x=...
(continues for ~1 page with same customer_id)
(and so on...)
Portanto, embora customer_ida ordem alfabética de 's não esteja correlacionada com as linhas fÃsicas, podemos fazer declarações como:
- há poucos IDs de cliente distintos por página
- há poucas páginas por ID
- há longas "execuções" de IDs ou, se você precisar de um
customer_id, provavelmente o encontrará em algumas páginas contÃguas - em termos de teoria da informação, acho que eles diriam que não há correlação, mas há uma alta "informação mútua"
O planejador de consultas pode usar informações como essa em estimativas, se uma não for executada explicitamente CLUSTER? Eu suponho que, se houver baixo correlationconforme relatado em pg_stats, ele adivinharia que as linhas são distribuÃdas uniformemente pelas páginas e podem ser pessimistas com vários planos.
(No meu análogo do mundo real, um Ãndice simples e não clusterizado tornou as coisas boas e rápidas de qualquer maneira, mas fiquei curioso quando notei o padrão nos dados.)
O planejador desconhece esse tipo de agrupamento e, portanto, não pode tomar decisões com base nele.
O método de amostragem em duas etapas usado pelo ANALYZE pode gerar amostras distorcidas nesta situação, possivelmente levando a uma subestimação drástica de n_distinct. É difÃcil prever quais podem ser as consequências disso sem investigar os detalhes de consultas individuais.