Le 2011-17-11 15h43, Marcelo Silva (IG) a écrit :
>
> select a.*, b.descricao, c.data_ven
> from mv_servicos_print a
> inner join mv_produtos b on(b.codigo = a.codigo)
> and(b.imprime = 'S') -- *** Aqui ***
> inner join mv_servicos_balcao c on(c.cod_key = a.cod_key_balcao)
> where (a.controle = 26116)
> and(a.obs not in('C'))
Por que há uma condição numa junção e outras na cláusula de seleção (WHERE)?
Não deveria, que eu saiba, fazer diferença para o planejador de
execução, mas o ideal é que todas as condições estejam organizadas na
cláusula de seleção, por exemplo:
SELECT
s.*,
p.descricao,
b.data_ven
FROM
mv_servicos_print s
INNER JOIN
mv_produtos p
USING codigo
INNER JOIN
mv_servicos_balcao b
ON (b.cod_key = s.cod_key_balcao)
WHERE s.controle = 26116
AND s.obs <> 'C'
AND p.imprime = TRUE
;
Código compreensível é esclarecedor, e ajuda a todos entenderem e,
talvez, ajudar.
> Acontece que se eu tirar a linha "and(b.imprime = 'S')"
E por que b.imprime não é BOOLEAN?
Outra coisa, cod_key parece má modelagem… talvez valha a pena analisar
se o uso de chaves naturais não poderia dispensar uma das junções.
> ele fica rapidinho, mas se deixa-la o SQL fica lento...
Teria de ter estrutura completa de todas as tabelas e índices
envolvidos, e análise de plano de execução da consulta.
> Bem imagino que tenha a ver com o seguinte, esse campo eu inseri depois de a
> tabela já estar populada, a unica coisa diferente foi isso, mas eu tenho
> alterado outras tabelas e não tenho tido esse problema.
E…?
Por favor, esse tipo de ‘análise’ — na verdade, especulação combinada a
tentativas-e-erro — só confunde. Tem-se de descobri o que realmente
acontece na execução que levantou a questão.
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
