Um índice composto também é bom para consultas no primeiro campo?

Digamos que eu tenho uma tabela com campos Ae B. Eu faço consultas regulares no A+ B, então criei um índice composto no (A,B). As consultas somente Atambém seriam totalmente otimizadas pelo índice composto?

Além disso, criei um índice A, mas o Postgres ainda usa o índice composto apenas para consultas A. Se a resposta anterior for positiva, acho que isso realmente não importa, mas por que ela seleciona o índice composto por padrão, se o Aíndice único está disponível?

Certamente é. Discutimos isso em detalhes na questão relacionada:

• Trabalho de índices no PostgreSQL

O espaço é alocado em múltiplos de MAXALIGN, normalmente 8 bytes em um sistema operacional de 64 bits ou (muito menos comum) 4 bytes em um sistema operacional de 32 bits. Se você não tiver certeza, verifique pg_controldata. Também depende dos tipos de dados das colunas indexadas (algumas requerem preenchimento de alinhamento) e do conteúdo real.

Um índice em, digamos, duas integercolunas (4 bytes cada) normalmente acaba exatamente do tamanho de um índice em apenas uma, onde outros 4 bytes são perdidos no preenchimento do alinhamento.

Nesse caso, não há realmente nenhuma desvantagem para o planejador de consultas usar um índice (a,b)- comparado a um índice apenas (a). E geralmente é preferível que várias consultas usem o mesmo índice. A chance de ele (ou parte dele) residir no cache (rápido) aumenta quando compartilhada.

Se você já mantém um índice ativado (a,b), não faz sentido criar outro índice apenas (a)- a menos que seja substancialmente menor. O mesmo não vale para (b,a)vs. (a). Siga o link na primeira linha para saber mais sobre isso.

Vindo da direção oposta, quando você precisar de um índice adicional como esse (a,b), considere soltar um índice existente apenas (a)- se possível. Geralmente não é possível, pois esse é o índice de uma PK ou UNIQUErestrição. Desde o Postgres 11, você pode simplesmente anexar bà definição de restrição com a INCLUDEcláusula. Detalhes no manual.

Ou crie o novo índice (b,a)para cobrir consultas apenas badicionalmente. Somente para condições de igualdade, a ordem das expressões de índice nos índices btree não importa. Porém, quando envolve condições de alcance. Vejo:

• Índice e desempenho de várias colunas

Existem possíveis desvantagens em incluir colunas adicionais em um índice, mesmo que isso use apenas o espaço perdido para o preenchimento do alinhamento:

• Sempre que a coluna adicional é atualizada, o índice agora também precisa de uma atualização, o que pode aumentar o custo das operações de gravação e criar mais inchaço no índice.
• As atualizações HOT (Heap Only Tuple) na tabela não são possíveis enquanto estiver envolvida qualquer coluna de índice.

Mais sobre atualizações HOT:

• Dados redundantes nas instruções de atualização

Como medir tamanhos de objeto:

• Meça o tamanho de uma linha da tabela do PostgreSQL

De acordo com sua pergunta, você tem uma tabela com os campos A e B. Se sua consulta for:

SELECT * FROM [YOUR TBL]
WHERE A='XXXX'

O Optimizer escolheu o índice Composto para evitar Extrair acesso aleatório!

É o caso se você apenas usar apenas o primeiro no predicado.

Ele fará a varredura se você usar as primeiras colunas da chave composta e a coluna não chave da chave composta.

Para enganá-lo, você pode simplesmente manipular predicados como este e depois a coluna sem chave:

[A, B] é o seu índice, [C] - outra coluna

Para utilizar o índice, você escreve como:

SELECT
    A,B,C,D,E
FROM 
    test
WHERE
   A=1
AND
   B=B
AND 
   C=3

... por que ele seleciona o índice composto por padrão, se o único índice A está disponível?

Ele usará o índice apenas no caso se houver um ou dois predicados [A] ou [A], [B]. Não o usará na ordem [B], [A] ou [A], [C]. Para poder utilizar o índice com a coluna adicional [C], você precisa aplicar o índice ordenando predicados como [A], [B] e [C].