Início / dba / Perguntas / 345727
Accepted
5ar
Asked: 2025-03-14 23:52:35 +0800 CST

Coluna de baixa granularidade: adicionar ao índice composto ou INCLUIR?

  • 772

Gostaria de saber qual seria a melhor prática na criação de índices para esses tipos de consultas:

select count(*) from my_table where high_granularity_column = $1 and low_granularity_column in ($2, $3)

Espera low_granularity_column-se que tenha entre 5 e 15 valores distintos e nem sempre tenha a mesma condição de pesquisa, portanto, usá-la para uma condição de índice parcial não é uma opção. Não se espera que a coluna seja usada para classificação e geralmente é um texttipo de dado de até 10 caracteres (por exemplo, uma coluna "status").

O objetivo é que o BD execute uma varredura somente de índice sempre que possível. Eu testei ambos os índices e eles têm desempenho similar:

create index idx_composite on my_table(high_granularity_column, low_granularity_column);

create index idx_with_include on my_table(high_granularity_column) include (low_granularity_column);

Minha pergunta é: qual é a melhor abordagem em termos de manutenção de índice para operações de inserção e atualização?

Além disso, estou esquecendo de algo em termos de desempenho de pesquisa em que um índice é melhor que o outro para conjuntos de dados maiores (por exemplo, 1 milhão de linhas em my_table)?

postgresql

1 respostas

  1. Best Answer

    Com o segundo índice com a INCLUDEcláusula, o PostgreSQL precisa escanear todas as entradas de índice where high_granularity_column = $1e então descartar aquelas onde low_granularity_columnnão atendem à sua condição.

    Com o primeiro índice, o PostgreSQL verificará apenas as entradas de índice que correspondem a ambas as condições, que são menos numerosas.

    Então o primeiro índice deve vencer, no que diz respeito ao desempenho. O segundo índice tem um melhor fan-out, porque low_granularity_columnnão é armazenado nas entradas não-folha, então o índice pode ser mais raso — no entanto, essa vantagem potencial não será perceptível, porque você só desce no índice duas vezes. No que diz respeito à manutenção do índice, ambos os índices devem ser igualmente caros.

    Se você não consegue medir um desempenho melhor com o primeiro índice, isso pode ter duas causas:

    1. O número de linhas correspondentes high_granularity_column = $1é tão baixo que a diferença realmente não importa.

    2. Você se esqueceu da VACUUMtabela, e as muitas buscas de heap na tabela são tão caras que ofuscam a diferença de desempenho das varreduras de índice.

    • 4

relate perguntas