Vamos lá:
Sort (cost=3.91..3.91 rows=1 width=47) (actual time=0.241..0.249 rows=5 loops=1)
Sort Key: razao
-> Seq Scan on cliente (cost=0.00..3.90 rows=1 width=47) (actual time=0.037..0.134 rows=5 loops=1)
Filter: (((razao)::text ~~ 'AN%'::text) OR ((fantasia)::text ~~ 'AN%'::text))
Total runtime: 0.427 ms
Depois, ele fez um seq_scan em cliente. O tamanho especificado dos valores da coluna cliente estão em torno de 47 bytes (isso não é tão importante). O custo total dessa operação é 3.9, e ela não custa nada pra iniciar ( 0.00..3.90 ) . O número estimado de linhas nessa busca foi de cinco linhas. O tempo foi de 0.037 até 0.134 (o tempo anterior foi gastado no filtro).
Primeiro, ele fez um filtro em razão e em fantasia.
Depois, foi feito um order by no resultado, usando a coluna razão, em cinco linhas. o tempo usado foi de 0.241 até 0.249).
Não usou índice. (aliás, acho que faltou um order by na query que vc passou não?)
Agora, a outra:
(select id, razao, fantasia
from cliente
WHERE razao like 'AN%')
UNION
(select id, razao, fantasia
from cliente
WHERE fantasia like 'n%')
Resultado:Unique (cost=7.53..7.55 rows=2 width=47) (actual time=0.274..0.305 rows=5 loops=1)
-> Sort (cost=7.53..7.53 rows=2 width=47) (actual time=0.267..0.275 rows=5 loops=1)
Sort Key: id, nome, fantasia
-> Append (cost=0.00..7.52 rows=2 width=47) (actual time=0.075..0.203 rows=5 loops=1)
-> Seq Scan on atendimentopessoa (cost=0.00..3.75 rows=1 width=47) (actual time=0.069..0.111 rows=4 loops=1)
Filter: ((nome)::text ~~ 'P%'::text)
-> Seq Scan on atendimentopessoa (cost=0.00..3.75 rows=1 width=47) (actual time=0.010..0.065 rows=1 loops=1)
Filter: ((fantasia)::text ~~ 'n%'::text)
Total runtime: 0.566 ms
Péssima idéia!
Repare só: table scan em atendimentopessoa, filtrando por nome.(n%)
Table scan em atendimento pessoa filtrando por fantasia (p%)
Os resultados foram unidos (contatenados - append)
Depois foram ordenados por id, nome, fantasia e as duplicatas foram removidas.
(Aliás, por esse plano, me parece que a query foi outra).
Bom Nelson, algumas perguntas:
1) Você é usuário de PostgreSQL já? Há quanto tempo? Qual versão você usa?
2) Você é usuário de algum outro banco? Está tentando migrar algum outro banco para o PostgreSQL? Pelo teor dos seus e-mails eu poderia quase que apostar que sim.
3) Se sim na resposta 2, seu outro banco usa índices nesse caso?
4) Esses dados são apenas pra testes? Ou são já uma aplicação real?
Bom, agora alguns pontos:
1) Não fique muito preocupado com o fato do PostgreSQL não estar utilizando o índice. Ao contrário do que se crê, nem sempre o índice é mais rápido, e com as estatísticas do banco atualizadas via ANALYZE, confie que o banco faz uma boa escolha. Como diz um pdf que eu peguei:
"You are not smarter than the planner (where you != Tom [Lane])"
Aliás, Tom Lane tem resistido a idéia de podermos fazer sugestões ao planejador (como por exemplo, o STRAIGHT_JOIN e o USE INDEX do MySQL). Isso porque ele considera isso com gambiarras - o otimizador deve ser bom e esperto o suficiente pra não depender desses artifícios.
2) Se esse código não for algo já em produção, não faz tanto sentido pensar em otimização já. Um dos maiores problemas da otimização é otimização prematura. É sério - só vale a pena otimizar quando vale a pena otimizar. Antes disso, qualquer otimização é 'correr atrás do vento'.
Pega uma tarde preguiçosa e dá uma lida: http://redivi.com/~bob/oscon2005_pgsql_pdf/OSCON_Explaining_Explain_Public.pdf
[]'s
- Walter
_______________________________________________ Grupo de Usuários do PostgreSQL no Brasil Antes de perguntar consulte o manual http://pgdocptbr.sourceforge.net/
Para editar suas opções ou sair da lista acesse a página da lista em: http://pgfoundry.org/mailman/listinfo/brasil-usuarios
