>>>>> "Vinicius" == Vinicius Santos <[email protected]> writes:
Vinicius> Certo. O que quis dizer é que o select está literamente passando
Vinicius> todos os registros da tabela de produto. Eu comprovei isto assim:
Vinicius> SELECT chave, produto, funcao_teste( chave ) FROM visao WHERE
produto
Vinicius> IN ( SELECT codigo FROM produtos_contados )
Vinicius> Dentro da funcao_teste eu dou um RAISE NOTICE, com o código do
Vinicius> produto, passado por parâmetro na função.
Vinicius> Eu pude verificar que o select dessa maneira, com IN, está
passando
Vinicius> em todos os produtos cadastrados.
Vinicius> Se eu fizer sem o IN, passando os valores literais, apenas os
Vinicius> registros corretos são lidos, também pude comprovar isto com a
saída
Vinicius> da funcao_teste.
É um seq scan porque é muito difícil correlacionar os critérios do
subselect genericamente com o where da tabela à esquerda e não tem como
prever quantos valores esse subselect vai retornar, assim o planner não
tem como avaliar o melhor plano antes da query começar a executar, e por
isso esse caso sempre vai ser um seq scan. Usando um join com um
critério explícito, o planner sabe qual índice usar antes da query rodar
e elabora um plano mais eficiente (presumindo que existam índices
adequados):
SELECT v.chave, v.produto
FROM visao v
JOIN produtos_contados pc
ON v.produto = pc.codigo;
O mesmo vale quando você usa valores literais no where, com um valor
constante no critério, o planner consegue olhar no índice e saber se a
quantidade de registros que passam no critério pedem um seq scan ou não.
Vinicius> O que me intriga, é que atualizamos a versão do kernel
rescentemente,
Vinicius> da 2.6 para 3.2, e ao mesmo tempo atualizamos o PostgreSQl do
8.4.8
Vinicius> para 8.4.12.
Vinicius> Teoricamente, a atualização não tem nada a ver. Certo?
Não, não tem nada a ver.
--
Eden Cardim
+55 11 9644 8225
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
