com chaves compostas, ainda preciso de índice para todas as colunas separadamente?

Se você tiver um índice exclusivo composto:

UNIQUE (parent_store_id, store_type, store_name)

Este índice é mais eficaz somente quando a consulta filtra colunas da esquerda para a direita nessa ordem exata.

Então, aqui: essas consultas se beneficiarão do índice:

WHERE parent_store_id = ...

WHERE parent_store_id = ... AND store_type = ...

WHERE parent_store_id = ... AND store_type = ... AND store_name = ...

E essas consultas não usarão o índice de forma eficiente:

WHERE store_type = ...

WHERE store_name = ...

WHERE store_type = ... AND store_name = ...

Para tais consultas, você deve criar índices separados em store_type ou store_name, dependendo do seu uso.

Observação : Adicionar índices gera sobrecarga de armazenamento e atualização. Portanto, adicione apenas o que for realmente usado em suas consultas.

O tipo de índice padrão é o BTree , que classifica seus parent_store_ids, cada um contendo seus store_types classificados, cada um com seus store_names classificados. A busca com base em todas as colunas ou nas colunas iniciais funciona bem. Outras combinações, especialmente as colunas mais à direita, não funcionam bem porque você precisa descer na árvore e coletá-las de cada ramo. Elas são classificadas independentemente umas das outras e são desduplicadas apenas internamente.

Dependendo do seu esquema, caso de uso e volumes, em vez de tentar antecipar todos os tipos de consultas e inundar seu banco de dados com uma BTree otimizada separada para cada combinação de colunas, você pode considerar um índice de filtro Bloom — é exatamente para isso que ele serve. Citando a documentação :

Este tipo de índice é mais útil quando uma tabela possui muitos atributos e as consultas testam combinações arbitrárias deles. Um índice btree tradicional é mais rápido que um índice bloom, mas pode exigir muitos índices btree para suportar todas as consultas possíveis, onde apenas um índice bloom é necessário. Observe, no entanto, que os índices bloom suportam apenas consultas de igualdade, enquanto os índices btree também podem realizar pesquisas de desigualdade e intervalo.

Se eu criar seu índice em uma configuração de teste com 100 mil linhas:
_{demonstração em db<>fiddle}

select setseed(.42);
create table t(parent_store_id, store_type, store_name)as
select (random()*1e5)::int
     , (random()*1e4)::int
     , md5((random()*9e4)::int::text)
from generate_series(1,1e5);

create unique index some_index on t(parent_store_id, store_type, store_name);
select pg_size_pretty(pg_relation_size('some_index'));

Obtenho 0,3 ms , 6 ms e 9 ms para pesquisas na 1ª, 2ª e 3ª colunas, respectivamente. Se eu substituir por um índice de filtro bloom:

create index bloomidx on t using bloom(parent_store_id, store_type, store_name);
select pg_size_pretty(pg_relation_size('bloomidx'));

Todas as três buscas levam cerca de 0,9 ms . O resumo é este:

ERROR:  access method "bloom" does not support unique indexes

O que significa que você ainda precisa manter o BTree para proteger a exclusividade e o Bloom só pode substituir os índices adicionais.

Se você realmente só tiver que lidar com essas três colunas, manter as poucas BTrees não deve ser um grande problema, mas quanto mais colunas você adicionar e mais variabilidade nos filtros de pesquisa você vir, mais perto estará do caso de uso ideal para o bloom.

o índice exclusivo acima lida com esses casos

Pode ser que sim ou não. Depende de vários fatores:

1. O número total de colunas, quantas delas estão no índice e quantas delas estão sendo selecionadas ou utilizadas pela consulta DML. Um índice de cobertura é preferível, por exemplo.
2. Tamanho da tabela - uma tabela pequena geralmente será submetida a varredura sequencial, independentemente da configuração do índice, simplesmente porque, para o planejador/otimizador, já é barato o suficiente para lê-la inteira. Se for grande, você verá varreduras de índice em quaisquer índices remotamente relacionados à consulta, simplesmente porque eles são normalmente muito menores, então é mais rápido lê-los e entendê-los do que a tabela.
3. Quando foi a última vacuumedição, analyzed, reindexed. Uma tabela nova, compacta e organizada é preferível a um índice desatualizado e inchado, e vice-versa.
4. Seja ele clustereditado por esse índice
5. Seletividade - se sua wherecondição faz referência à primeira coluna, mas de certa forma está abordando a tabela inteira, não faz sentido usar o índice, a menos que seja um índice de cobertura.

A lista não é exaustiva. Você pode experimentar set enable_seqscan=off;e ver que, embora o Postgres consiga obter os valores solicitados usando o índice, a varredura sequencial às vezes é realmente o método mais rápido.

ainda preciso criar índices separados para cada uma dessas colunas

Somente se você puder arcar com a pequena, mas diferente de zero, latência adicional em insert/ update/ delete, que precisa ser refletida em cada índice, além do espaço para acomodar os índices, além da manutenção dos índices ( reindexque não acontece por si só, eles ficam inchados e desatualizados). Além disso, se você não puder arcar com a diferença no tempo de execução das consultas nas colunas finais.