Caro William;
Obrigado pela resposta.
Tenho vários programas em PL/SQL compostos por milhares de linhas, que
efetuam uma série de cálculos, utizando, inclusive, de recursividade, e
gostaria de portá-los para o Post. Infelizmente, na versão 8.2.7, tais ficaram
extremamente lentos, inviabilizando uma das etapas do projeto. Não cheguei a
testar em nenhuma outra versão.
A fim de tentar descobrir o porquê deste problema, recorrí à esta lista,
colocando duas funções apenas para exemplificar o mesmo e entendí, segundo
explicações dos colegas, que o PL/pgSQL não é a linguagem mais apropriada para
este tipo de operação.
Agradeço à você e aos demais integrantes da lista por me auxiliarem.
Márcio de Figueiredo Moura e Castro
________________________________
De: William Leite Araújo <[email protected]>
Para: Comunidade PostgreSQL Brasileira <[email protected]>
Enviadas: Terça-feira, 29 de Setembro de 2009 15:03:07
Assunto: Re: [pgbr-geral] Res: Res: Res: Performance usando funções em PLPGSQL
comparadas ao PL/SQL no Oracle
2009/9/21 MARCIO CASTRO <[email protected]>
Caro Rafael:
>
> Obrigado pela resposta.
>
> A "select fib(35);" retorna 9227465, e select fnc_fibonacci(35) retorna
> 14930352. Não sei qual está certa ou errada.
>
> Estou utilizando a 8.2.7 por a mesma já estar instalada aquí e no cliente. A
> versão 8.4 tem "WITH RECURSIVE", mas tal não seria compatível com o mesmo
> código escrito no Oracle.
>
> A minha intenção ao usar o fibonacci foi para mensurar performance. Eu não
> sabia que o Postgres não trata a recursividade corretamente, portanto, vou
> desconsiderá-la.
> De qualquer forma, também utilizei um outro exemplo com um simples LOOP
> (function1), e a diferença também foi absurda.
>
Não conheço o Oracle, mas sei que o Portgresql usa parâmetros de
configuração bem modestos e que a versão 8.4 possui inúmeros incrementos de
performance em relação à 8.2.
Além disso, TODO procedimento PLPGSQL roda com isolamento de transação.
Assim sendo, a resposta do seu procedimento sempre será 0. Para pegar o
instantâneo do tempo dentro da função, use "timeofday()".
Baseado nestes, entendí que o PL/pgSQL é muito inferior em termos de
performance do que o PL/SQL no Oracle.
Na minha opinião, um entendimento precipitado. A alguns anos atrás, na
versão 8.1 do Postgresql, criei procedimentos que trabalhavam na migração de
dados cujo tipo principal das chaves era NUMERIC. Bastou trocar o tipo para
INTEGER e tive ganhos "obcenos" de tempo (6 horas para 6 minutos, + ou - )
Por favor, me desculpe se escreví alguma bobagem, ou não fui claro o
suficiente. Ficarei muito agradecido se você ou os demais membros postarem mais
dicas de performance ou outros exemplos que eu possa utilizar. Entenda também
que a diferença de performance foi tão grande à ponto de eu desconfiar de um
problema no servidor Linux.
>
>
>
>Atenciosamente,
>
>Márcio de Figueiredo Moura e Castro
>
--
William Leite Araújo
Mobile Solution Manager - QualiConsult
Analista de Banco de Dados
____________________________________________________________________________________
Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
