Paulo, boa tarde...
No teu email inicial, você disse que criou o indice xix1_cliente em desenv e
resolveu, mas não resolveu em produção. Olhando o teu explain, podemos ver
que um dos pontos de impacto, como falado anteriormente é a entidade
logradouro_bairro:
Desenv:
- Index Scan using logradouro_bairro_pkey on
logradouro_bairro logradouro3_ (cost=0.00..6.07 rows=1 width=8) (actual
time=9.047..9.048 rows=1 loops=284) Index Cond: (logradouro3_.lgbr_id =
clienteend2_.lgbr_id)
Produção:
- Seq Scan on logradouro_bairro
logradouro3_ (cost=0.00..2033.86 rows=117186 width=8) (actual
time=0.011..359.858 rows=117186 loops=1)
Temos um acesso sequencial ai... E nesse ponto, o custo da consulta comeca a
ficar muito elevada.
Dá uma olhada nessa entidade em produção... Se para o atributo em questão
você tem um indice...
Outra coisa, para melhorar um pouco o banco na hora do parse, inverta a
ordem dos atributos no teu relacionamento (o analisador de consultas
provavelmente vai fazer isso pra vc, mas não custa nada dar uma
maozinha... rsss), algo como:
select count(distinct cliente0_.clie_id) as col_0_0_
from cadastro.cliente cliente0_
left outer join cadastro.cliente_tipo clientetip1_ on
clientetip1_.cltp_id = cliente0_.cltp_id
left outer join cadastro.cliente_endereco clienteend2_ on
clienteend2_.clie_id = cliente0_.clie_id
left outer join cadastro.logradouro_bairro logradouro3_ on
logradouro3_.lgbr_id = clienteend2_.lgbr_id
left outer join cadastro.bairro bairro4_ on bairro4_.bair_id =
logradouro3_.bair_id
left outer join cadastro.municipio municipio5_ on municipio5_.muni_id =
bairro4_.muni_id
where (upper(cliente0_.clie_nmcliente) like 'EDNALDO F%') and
municipio5_.muni_id=960
Considere também a possibilidade de substituir os left outer join por
inner join (como falado tb), claro se a lógica do sistema permitir... Pois
o custo de outer joins pro banco é alto...
Espero ter ajudado.
Att,
--
Charly Frankl
http://javadevilopers.blogspot.com/
charlyfra...@gmail.com
Linux user #391083
2009/7/31 paulo matadr saddon...@yahoo.com.br
Boa tarde euler,
nao houve mudanca no plano..fui ate 64 de work e nada
--
*De:* Euler Taveira de Oliveira eu...@timbira.com
*Para:* Comunidade PostgreSQL Brasileira
pgbr-geral@listas.postgresql.org.br
*Enviadas:* Quarta-feira, 29 de Julho de 2009 18:14:19
*Assunto:* Re: [pgbr-geral] Res: Res: Analise de uso de index entre 8.2 ou
8.3
paulo matadr escreveu:
Os parametros do servidor aparentemente importantes sao:
Qual é o valor de work_mem? Você tentou fazer:
SET work_mem to 16MB;
EXPLAIN ANALYZE SELECT ...;
SET work_mem to 8MB;
EXPLAIN ANALYZE SELECT ...;
SET work_mem to 32MB;
EXPLAIN ANALYZE SELECT ...;
O plano mudou?
Outra coisa é que você está utilizando LEFT JOIN em todas as junções. Eles
são
realmente necessários ou tem algum deles que pode ser um INNER JOIN
(aqueles
cuja chave estrangeira não pode ser nula)? Junções externas *não*
restringem
tanto o conjunto de dados quanto junções internas e, tendem a ser mais
custosas.
--
Euler Taveira de Oliveira
http://www.timbira.com/
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
--
Veja quais são os assuntos do momento no Yahoo! + Buscados: Top
10http://br.rd.yahoo.com/mail/taglines/mail/*http://br.maisbuscados.yahoo.com/-
Celebridadeshttp://br.rd.yahoo.com/mail/taglines/mail/*http://br.maisbuscados.yahoo.com/celebridades/-
Músicahttp://br.rd.yahoo.com/mail/taglines/mail/*http://br.maisbuscados.yahoo.com/m%C3%BAsica/-
Esporteshttp://br.rd.yahoo.com/mail/taglines/mail/*http://br.maisbuscados.yahoo.com/esportes/
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
