Charly, > É por ai mesmo. Na verdade, você pode ter os 50 índices na tua tabela, mas > quando for consultá-la o SGBD vai eleger UM índice a ser utilizado para a > consulta. Logo, ter 50 índices não é garantia de melhoria na performance da > pesquisa, mas alguns índices bem planejados vão com certeza ajudar. > > Resumindo, a cada consulta o SGBD elege APENAS UM índice da entidade para > ser utilizado na consulta.
Contra-exemplo trivial: --Cidades do Acre com homônimos em outro estado: select distinct c2.nomecidade from tbcidade c2 inner join tbcidade c on c.nomecidade = c2.nomecidade and c.uf<>c2.uf where c2.uf='AC' Esta consulta me gerou o seguinte plano: "HashAggregate (cost=106.66..106.88 rows=22 width=13)" " -> Nested Loop (cost=2.43..106.60 rows=26 width=13)" " Join Filter: ((c.uf)::text <> (c2.uf)::text)" " -> Bitmap Heap Scan on tbcidade c2 (cost=2.43..28.09 rows=23 width=16)" " Recheck Cond: ((uf)::text = 'AC'::text)" " -> Bitmap Index Scan on i1tbcidade (cost=0.00..2.42 rows=23 width=0)" " Index Cond: ((uf)::text = 'AC'::text)" " -> Index Scan using a1tbcidade on tbcidade c (cost=0.00..3.40 rows=1 width=16)" " Index Cond: ((c.nomecidade)::text = (c2.nomecidade)::text)" E olha que nem precisei apelar para mais de uma tabela, UNIONs, EXISTS, filtros com OR ou sub-selects! Como pode ver, o otimizador notou, pela distribuição dos dados, que compensa usar um índice diferente para cada citação da tabela dentro da mesma consulta (i1tbcidade e a1tbcidade). Não sei se só eu noto isso, mas a maioria das querys com sub-selects ou cláusulas EXISTS que observei na minha aplicação usam índices diferentes para a mesma tabela. Logo, no meu caso, ter um monte de índices na mesma tabela compensa sim, e muito. Atenciosamente, Mozart Hasse _______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
