Caro Euler:
a -
"Discordo. Não *generalize* as coisas; já vi várias instalações PostgreSQL com
performance superior a anterior (aka Or*cle)."
Não estou generalizando; é verdade mesmo. Por favor; não vamos começar uma
discussão infundada, que de nada acrescentará à lista. Mas você pode nos enviar
a estrutura deste "eu já ví", e então poderemos repetir os mesmos testes, ok?
b -
"Você _não_ mostrou a função em PL/SQL e nem a equivalente em PL/pgSQL."
Se você procurar o histórico da lista, verificará as duas funções utilizadas
como exemplo, que são muito simples. E irá verificar também que um outro membro
desta compilou e rodou a rotina do Post em seu próprio servidor. Mas se estas
não se adequam, por favor, envie suas próprias funções, tabelas ou demais
objetos; acaso cometido algum erro, pedirei desculpas a todos.
c -
"Oracle mais rápido? Eu *não* vi esses resultados em [1][2]. Você só mostrou os
resultados do Oracle e _não_ do PostgreSQL com a função em C"
Como explicado, tentamos migrar uma aplicação com milhares de linhas de
código em PL/SQL (Oracle) para o Postgres (PG/plSQL). Quem efetuou este pedido
foi O PRÓPRIO CLIENTE, que, com certeza, estava querendo diminuir os custos
portando a sua aplicação para o PostgreSQL. O cliente NÃO QUERIA REESCREVER
TUDO EM C ou em qualquer outra linguagem, mas aproveitar ao máximo o código
existente!
d -
"A conclusão daquela discussão foi que você estava "batendo em espantalho"; use
os métodos adequados para obter melhor desempenho."
Continuo sem saber o que significa "batendo em espantalho" (nem me interessa
saber), e se você não for capaz de dar maiores explicações sobre o que você
chama de "métodos adequados", ninguém irá entender.
e -
"Para isso precisamos pagar um bom $$$ para associarmos e termos direito de
fazer tais testes. E, é claro, termos hardwares disponíveis para realizar os
testes. (Sem uma grande empresa com acesso aos vendedores de hardware, fica
difícil realizarmos tal tarefa)."
Sim, é verdade. Mas que empresa de hardware irá recomendar um produto sem
ganhar nada em cima? A mesma pode até "vender o peixe" com o Postgres, mas será
que a mesma declararia que tal produto é mais rápido do que o banco A ou B, sem
possuir nenhuma comprovação de tal fato?
Mas se você GARANTE, ótimo, é só comprovar, ok? Aliás, na semana passada eu
conhecí um cara que GARANTE que "o Caché é o banco mais rápido do mundo".
Perguntado sobre como comprovar esta declaração, este respondeu que a mesma "é
baseada em vivência e experiância profissional". Perguntado se o mesmo já havia
trabalhado com outros bancos, o mesmo respondeu "nenhum"...
Termino esta repetindo que você, ou qualquer outro membro da lista, pode
escrever as rotinas que julgar mais adequadas ("métodos adequados", tabelas, ou
seja o que for), que irei testá-las com o maior prazer. Aliás, se mais alguém
quiser acompanhar estes testes in loco, é só chegar aquí na empresa - estou em
BH, na Floresta. Os servidores serão os mesmos dos testes anteriores, e a única
exigência é que tudo possa rodar com um mínimo de alterações.
E se alguém quiser verificar por sí só no Oracle, é só baixar gratuitamente o
software no site da mesma - não são necessárias licenças para estudar, efetuar
testes ou criação de protótipo.
Abaixo as rotinas utilizadas, no Postgres e no Oracle.
Atenciosamente,
Márcio de Figueiredo Moura e Castro
--------------------------------------------------
-- FIB
--------------------------------------------------
-- FIB NO ORACLE
create or replace
FUNCTION fib(fib_for integer)
RETURN integer AS
BEGIN
IF fib_for < 2 THEN
RETURN fib_for;
END IF;
RETURN fib(fib_for - 2) + fib(fib_for - 1);
END;
-- FIB NO POSGRES
CREATE OR REPLACE FUNCTION fib(fib_for integer)
RETURNS integer AS
$BODY$
BEGIN
IF fib_for < 2 THEN
RETURN fib_for;
END IF;
RETURN fib(fib_for - 2) + fib(fib_for - 1);
END;
$BODY$
LANGUAGE 'plpgsql' IMMUTABLE;
ALTER FUNCTION fib(integer) OWNER TO postgres;
--------------------------------------------------
-- FUNCTION1
--------------------------------------------------
-- FUNCTION1 NO ORACLE
create or replace
FUNCTION FUNCTION1 return number AS
i INTEGER;
s integer;
v_tempo number;
BEGIN
SELECT (EXTRACT(minute FROM current_timestamp) * 60) + EXTRACT(second FROM
current_timestamp) into v_tempo FROM dual;
FOR i IN 1 .. power(10,8) LOOP
s := s + 1;
END LOOP;
SELECT ((EXTRACT(minute FROM current_timestamp) * 60) + EXTRACT(second FROM
current_timestamp)) - v_tempo into v_tempo FROM dual;
RETURN v_tempo;
END FUNCTION1;
-- FUNCTION1 NO POSTGRES
CREATE OR REPLACE FUNCTION function1()
RETURNS integer AS
$BODY$
DECLARE
i INTEGER;
s integer;
BEGIN
FOR i IN 1 .. power(10, 8) LOOP
s := s + 1;
END LOOP;
RETURN 0;
END;
$BODY$
LANGUAGE 'plpgsql' IMMUTABLE;
ALTER FUNCTION function1() OWNER TO postgres;
________________________________
De: Euler Taveira de Oliveira <[email protected]>
Para: Comunidade PostgreSQL Brasileira <[email protected]>
Enviadas: Sexta-feira, 22 de Janeiro de 2010 13:07:27
Assunto: Re: [pgbr-geral] Res: Digest pgbr-geral, volume 35, assunto 94
MARCIO CASTRO escreveu:
> Trabalho com o Postgres e com o Oracle, e relato que a diferença entre
> os mesmos é abismal.
Discordo. Não *generalize* as coisas; já vi várias instalações PostgreSQL com
performance superior a anterior (aka Or*cle).
> Tentamos inclusive importar um sistema com milhares de funções e
> procedimentos em PL/SQL (Oracle 10g) para o PL/pgSQL, mas os primeiros
> testes nos revelaram que a performance cairia demais, tornando o projeto
> inviável.
Você _não_ mostrou a função em PL/SQL e nem a equivalente em PL/pgSQL.
> Na época, cheguei até a buscar auxílio na lista, escrevendo dois
> pequenos exemplos para isto. Alguns até me auxiliaram, propondo que as
> rotinas fossem reescritas em C, mas mesmo assim o Oracle foi mais rápido.
Oracle mais rápido? Eu *não* vi esses resultados em [1][2]. Você só mostrou os
resultados do Oracle e _não_ do PostgreSQL com a função em C.
A conclusão daquela discussão foi que você estava "batendo em espantalho"; use
os métodos adequados para obter melhor desempenho.
> PS: http://www.tpc.org/tpcc/results/tpcc_perf_results.asp
> Continuo torcendo para que um dia vejamos o Post nesta lista!
>
Para isso precisamos pagar um bom $$$ para associarmos e termos direito de
fazer tais testes. E, é claro, termos hardwares disponíveis para realizar os
testes. (Sem uma grande empresa com acesso aos vendedores de hardware, fica
difícil realizarmos tal tarefa).
[1]
http://listas.postgresql.org.br/pipermail/pgbr-geral/2009-September/017497.html
[2]
http://listas.postgresql.org.br/pipermail/pgbr-geral/2009-September/017498.html
--
Euler Taveira de Oliveira
http://www.timbira.com/
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
____________________________________________________________________________________
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
