Mozart, boa tarde... Acho que não entendeu bem quando eu usei o termo
"apenas um índice por tabela".


> 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).


Como você mesmo colocou, o otimizador optou por "usar um índice diferente
para *cada citação da tabela* dentro da mesma consulta". Logo, percebe-se
que o otimizador trata a mesma entidade como entidades diferente (c e c1).
Se você observar, ele optou apenas por um índice para cada entidade sendo:
-> Index Scan using a1tbcidade on tbcidade c
-> Bitmap Heap Scan on tbcidade c2  (cost=2.43..28.09 rows=23 width=16)"
                     ->  Bitmap Index Scan on i1tbcidade
ou seja,
-> a1tbcidade para tbcidade c
-> i1tbcidade  para tbcidade c2

Note a diferença nos usos.




> 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.
>

Segue aqui o mesmo conceito definido anteriormente. Quando você utiliza uma
subconsulta, o otimizador trata de fato como um novo uso para a entidade.
Logo, ele pode eleger um índice diferente na consulta interna (tb1)
diferente do eleito pra consulta externa (tb1-a ).



Logo, no meu caso, ter um monte de índices na mesma tabela compensa sim, e
> muito.
>

Não creio ser esse o tema do debate, se no teu caso compensa ou não. Mesmo
porque, ninguém aqui alem de você pode julgar isso.


Agora, voltando ao tema de muitos índices por tabela, como exposto
anteriormente pelos colegas Euler e Fabrízio, o PostgreSQL consegue nas
novas implementações simular índices bitmap (com seus custos, mas consegue).
Inclusive no exemplo que enviou podemos observar o PostgreSQL fazendo uso do
recurso, e percebe-se notadamente o que foi exposto na documentação:
"Recheck Cond: ((uf)::text = 'AC'::text)".


Agora, com relação a expressão "Não sei se só eu noto isso...", desculpe-me
se em algum momento meus posts pareceram ser pessoais, muito pelo contrário,
apenas tentei colaborar com o debate, mesmo porque é um tema muito
interessante. E como falei, todos temos o direito de discordar, errar e
acertar dentro dos nossos debates, é isso que torna esta lista construtiva,
os erros e acertos de cada um!



Um grande abraço,


-- 
Charly Frankl
http://javadevilopers.blogspot.com/
[email protected]
Linux user #391083
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Responder a