2014-02-05 Daniel Cordeiro <dmora...@gmail.com>: > > Em 05-02-2014 11:55, Matheus de Oliveira escreveu: > ... > > ', uma vez que a view vai gerar todos os dados e só depois é que o > planejador realizará a restrição através do cláusula > >
> WHERE e ordenações necessárias. > >> >> > humm... Sua afirmação não está correta. [...] > Eu até diria que nesse exemplo específico a view me parece até mais > adequada e mais fácil de manter do que a função. > > Como eu falei no email que respondi para Euler: My bad :-( > Tranquilo, acontece. Só corrigi para não deixar erros assim no histórico... :-) > >> Minha sugestão é criar uma função que realiza a consulta já adicionando >> as restrições necessárias para a triagem inicial dos dados desejados. >> [...] >> >> Eu só recomendaria, nesse caso especificamente, a usar uma função SQL ao >> invés de PL/pgSQL: >> >> CREATE OR REPLACE FUNCTION sp_lancamentos(IN CODCONTA varchar) >> RETURNS TABLE(i int, c1 text,c2 text, c text) >> AS $$ >> SELECT id,conta,campo1,campo2 FROM lancamentos WHERE conta = >> CODCONTA; >> $$ >> LANGUAGE SQL; >> >> Para chamá-la: > > SELECT * FROM sp_lancamentos('Produtivo'); > > (a chamada em si seria igual à PL/pgSQL, só quis exemplificar)] > > Claro, usei o plpgsql por me basear em algo que já tinha, e o mesmo > depende dos recursos além da sql. > > Ah sim, entendo muito bem. Só quis deixar claro que quando queremos **simples**mente uma espécie de "view parametrizada" a troca natural é para uma função em linguagem SQL. Na verdade foi mais um complemento à sua resposta. > > >> Para uma function muito grande e com muitas variáveis para >> substituição, vale a pena utilizar a cláusula EXECUTE no RETURN QUERY (isso >> já me salvou de vários problemas em functions com mais mais de 1500 linhas >> e código e dezenas de variáveis)* 2*: >> >> >> * .... RETURN QUERY EXECUTE 'SELECT id,conta,campo1,campo2 FROM >> lancamentos WHERE conta = $1' USING CODCONTA;* >> .... >> >> >> > Ah? Por quê? Eu particularmente tento evitar o EXECUTE ao menos que > estritamente necessário. Lembre-se que ele não pode ser otimizado pelo > PL/pgSQL para armazenar o plano de execução. > > Eu também não. Mas neste meu caso, após o crescimento de dados em > alguns clientes (alguns milhões de registros em dezenas de tabelas), o > QueryPlan dentro da procedure passou a ser tratado de maneira totalmente > diferente se comparado à execução da mesma query já com os valores > prefixados nas condicionais e subqueryes fora da procedure. Aparentemente, > como o prepare acontece antes do conhecimento dos parâmetros na procedure, > o planejador gerava um plano de execução mais custoso. (novamente, esta foi > a minha impressão sobre o caso). > > Estou falando da mesma consulta rodando em 5 horas dentro da procedure e 7 > segundos rodando fora. Inicialmente pensei que fosse a adoção do RETURN > QUERY. Ao modificar a procedure fazendo o retorno com o EXECUTE, o tempo > foi normalizado e o custo de operação dentro e fora da procedure ficou, de > fato, irrelevante. > > Sim, isso realmente poderia acontecer. Creio que o seu caso foi numa versão anterior à 9.2, correto? Na 9.2 o modelo de gerar plano de execução para "prepared statements" mudou, e ficou bem melhor. Agora o plano é gerado no EXECUTE, quando já são conhecidos os valores. Recomendo você a testar novamente essas funções numa versão mais recente (9.2 ou 9.3) e verificar se o comportamento ainda é o mesmo. Se o fizer, por favor compartilhe os resultados com os colegas, ;-)... > > > >> Lembrando que estas ações podem dificultar a análise de um problema >> futuro, pois o EXPLAIN não vai detalhar o conteúdo interno executado na >> função e nem nos logs. >> >> > +1. Otimizar funções é uma tarefa bem árdua. Só uma dica, a extensão > auto_explain pode ajudar nessa tarefa. ;-) > > > Obrigado pela dica! Vou estudar a extensão para verificar sua adoção em > nosso ambiente. > > É, na minha opinião, um pré-requisito para quem usa muitas funções. Atenciosamente, -- Matheus de Oliveira Analista de Banco de Dados Dextra Sistemas - MPS.Br nível F! www.dextra.com.br/postgres
_______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral