Re: [pgbr-geral] Res: Digest pgbr-geral, volume 35, assunto 94
Se o seu sistema j estava escrito em Oracle e voc apenas migrou para o Postgresql como voc queria que tivesse o mesmo desempenho? Voc teria que rever a sua escrita porque com certeza o cdigo que voc escreveu foi otimizado para rodar no Oracle, para fazer a migrao voc deveria ter o mesmo cuidado e analisar o cdigo que foi portado para o Postgresql. Tambm j ouvi de fonte confivel que em testes realizados comparando os dois bandos o PG chegou a ser at 50% mais rpido que o Oracle, mas claro que esse teste no foi publicado e nem ser. Abrao, Fabiano Machado Dias Euler Taveira de Oliveira escreveu: MARCIO CASTRO escreveu: Trabalho com o Postgres e com o Oracle, e relato que a diferena entre os mesmos abismal. Discordo. No *generalize* as coisas; j vi vrias instalaes PostgreSQL com performance superior a anterior (aka Or*cle). Tentamos inclusive importar um sistema com milhares de funes 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 invivel. Voc _no_ mostrou a funo em PL/SQL e nem a equivalente em PL/pgSQL. Na poca, cheguei at a buscar auxlio 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 rpido. Oracle mais rpido? Eu *no* vi esses resultados em [1][2]. Voc s mostrou os resultados do Oracle e _no_ do PostgreSQL com a funo em C. A concluso daquela discusso foi que voc estava "batendo em espantalho"; use os mtodos 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 disponveis para realizar os testes. (Sem uma grande empresa com acesso aos vendedores de hardware, fica difcil 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 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Performance
Boa tarde, Há uma discussão sobre desempenho de Oracle vs. PostgreSQL ocorrendo em outro tópico, mas estamos indo em uma discussão complicada e com argumentos complicados de ambos os lados. Honestamente, Oracle é um ótimo banco, assim como é o PostgreSQL (que é meu banco de dados predileto). Se vamos fazer um comparativo entre ambos, precisamos primeiro fazer um modelo coerente de testes e executá-los. E também precisamos levar em consideração o design e a função de cada linguagem de cada banco de dados. Eu gostaria muito de ver um comparativo bem montado, mas não tenho hardware nem tempo necessário para executar o mesmo. Por experiência própria, imagino ver um desempenho próximo entre os dois (obviamente ambos os bancos bem configurados), sendo que um brilharia mais em alguns pontos e o outro em outros. Já fui DBA de Oracle (na versão 8) e sou hoje de PostgreSQL (desde a versão 8.0), em nenhum dos dois casos descepcionei-me. Na realidade, ambos os bancos continuam a me surpreender regularmente. Se houver quem deseje elaborar um estudo desses, acho que seria de grande valia. Contudo, peço encarecidamente que não façamos afirmações amadoras do tipo Oracle é melhor que PostgreSQL ou PostgreSQL é melhor de Oracle sem dados reais ou apenas baseados em um caso específico, a não ser em conversas de bar. Um estudo bem montado poderia inclusive diminuir a incidência de afirmações amadoras como essas. Abraços, -- André de Camargo Fernandes PS: Não sei se seria possível fazer um estudo desses e publicar pois não sei se a Oracle permitiria a divulgação do mesmo (desconheço a licensa da Oracle, não sei se tem alguma cláusula referente a isso). ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Performance
2010/1/23 Andre Fernandes fernandes.an...@gmail.com: PS: Não sei se seria possível fazer um estudo desses e publicar pois não sei se a Oracle permitiria a divulgação do mesmo (desconheço a licensa da Oracle, não sei se tem alguma cláusula referente a isso). Concordo com tudo o que disse, com exceção das conversas de bar que costumam ser muito construtivas... Participe e tire suas conclusões. Quanto a licença[1] da Oracle: - disclose results of any program benchmark tests without our prior consent. [1] http://www.o_r_a_c_l_e.com/technology/software/popup-license/standard-license.html PS Obviamente retirem os sublinhados. Abraço! -Leo -- Leonardo Cezar http://www.aslid.org.br http://postgreslogia.wordpress.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Performance
Concordo, no entanto se você foi DBA Oracle deveria saber que o tal estudo não poderá ser divulgado e talvez nem realizado sem a autorização da Oracle! Abraço, Fabiano Machado Dias Boa tarde, Há uma discussão sobre desempenho de Oracle vs. PostgreSQL ocorrendo em outro tópico, mas estamos indo em uma discussão complicada e com argumentos complicados de ambos os lados. Honestamente, Oracle é um ótimo banco, assim como é o PostgreSQL (que é meu banco de dados predileto). Se vamos fazer um comparativo entre ambos, precisamos primeiro fazer um modelo coerente de testes e executá-los. E também precisamos levar em consideração o design e a função de cada linguagem de cada banco de dados. Eu gostaria muito de ver um comparativo bem montado, mas não tenho hardware nem tempo necessário para executar o mesmo. Por experiência própria, imagino ver um desempenho próximo entre os dois (obviamente ambos os bancos bem configurados), sendo que um brilharia mais em alguns pontos e o outro em outros. Já fui DBA de Oracle (na versão 8) e sou hoje de PostgreSQL (desde a versão 8.0), em nenhum dos dois casos descepcionei-me. Na realidade, ambos os bancos continuam a me surpreender regularmente. Se houver quem deseje elaborar um estudo desses, acho que seria de grande valia. Contudo, peço encarecidamente que não façamos afirmações amadoras do tipo Oracle é melhor que PostgreSQL ou PostgreSQL é melhor de Oracle sem dados reais ou apenas baseados em um caso específico, a não ser em conversas de bar. Um estudo bem montado poderia inclusive diminuir a incidência de afirmações amadoras como essas. Abraços, -- André de Camargo Fernandes PS: Não sei se seria possível fazer um estudo desses e publicar pois não sei se a Oracle permitiria a divulgação do mesmo (desconheço a licensa da Oracle, não sei se tem alguma cláusula referente a isso). ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Performance
Em 23 de janeiro de 2010 18:06, fabi...@wolaksistemas.com.br escreveu: Concordo, no entanto se você foi DBA Oracle deveria saber que o tal estudo não poderá ser divulgado e talvez nem realizado sem a autorização da Oracle! Abraço, Fabiano Machado Dias Como quando fui DBA de Oracle não me preocupava com isso, não tinha sequer olhado para esse aspecto jurídico. Falha minha (por isso disse que não sabia se era possível). Aliás, isso foi antes de eu conhecer o postgreSQL (na época conhecia apenas Oracle, MySQL e MS SQL Server). Abraços, -- André de Camargo Fernandes ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Performance
Em 23 de janeiro de 2010 17:55, Leonardo Cezar lhce...@gmail.com escreveu: Concordo com tudo o que disse, com exceção das conversas de bar que costumam ser muito construtivas... Participe e tire suas conclusões. Sem dúvida costumam ser, fui um pouco extremista em minha afirmação, peço desculpas, não foi esse o intento. Abraço! -Leo -- Leonardo Cezar http://www.aslid.org.br http://postgreslogia.wordpress.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- André de Camargo Fernandes ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Postgresql.conf
Bom dia A algum tempo atrás um participante da lista (Se nção me engano foi o Sr. Fabio Telles) disponibilizou um documento com comentários a respeito de cada um dos parâmetros do postgresql.conf. Além da definição técnica havia também a visão prática do autor a respeito de cada parâmetro. A pergunta é a seguinte: Alguém tem algo parecido para a versão 8.4, pois aquele documento parou na 8.2? Ou algum texto que não seja o manual falando dos principais parâmetros ? Estou migrando para esta versão, estudando o manual mas a visão prática somente pode ser dada por quem já está trabalhando com essa versão ? Obrigado -- Jose Mario Barduchi Supervisor de Banco de Dados Grupo Wheaton Brasil Telefone : (11) 4355-1207 Site: http://www.wheatonbrasil.com.br E-Mail: jose.bardu...@wheatonbrasil.com.br ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Performance
Olá André 2010/1/23 Andre Fernandes fernandes.an...@gmail.com Em 23 de janeiro de 2010 18:06, fabi...@wolaksistemas.com.br escreveu: Concordo, no entanto se você foi DBA Oracle deveria saber que o tal estudo não poderá ser divulgado e talvez nem realizado sem a autorização da Oracle! Abraço, Fabiano Machado Dias Como quando fui DBA de Oracle não me preocupava com isso, não tinha sequer olhado para esse aspecto jurídico. Falha minha (por isso disse que não sabia se era possível). Aliás, isso foi antes de eu conhecer o postgreSQL (na época conhecia apenas Oracle, MySQL e MS SQL Server). Eu já fiz um estudo desses mas por implicações jurídicas, inclusive consultei um advogado especialista na área digital, não posso divulgar. Eu gerencio um banco de dados com 2.5 T em PostgreSQL que migrei de um Oracle 1'0g. Conheços outros testes comparativos que existem, mas também que não podem ser divulgados. Em minha opnião nunca haverá um dia em que um comparativo desses poderá ser divulgado. Até o pessoal do time internacional nunca fez isso (pelo menos não tenho conhecimento). Assim como muitos, tenho minha experiência com PostgreSQL desde a versão 7.3 e realizei algumas migrações de outros SGDBs para ele. Nunca existiu algum cliente que tenha me pedido a migração e que tenha reclamado depois. No máximo, devido a resistencia, o que ocorreu foi a substituição do DBA mesmo após sua capacitação devida. Eu negocio tudo. Infelizmente algumas pessoas não aceitam migrar de uma tecnologia para outra e se mantem resistentes mesmo que quem esteja pagando informe do desejo da migração. Dessa discussão toda o que posso afirmar é que cada caso é um caso, se a PL/pgSQL não me atende eu procuro sempre uma outra forma de implementar e conseguir a performance que preciso. Meu time implementa PL ´s em várias linguagens, PL/pgSQL, PL/PHP, PL/Perl(Perl faz coisas bizarras :-P, mas faz), até PL/Java. Sei que nem sempre há como pagar um profissional que consiga fazer isso mas quando precisamos, procuramos aprender e implementar. Tem dado certo nos últimos 2 anos. Mas de qualquer forma, muito boa sua atitude de pelo menos propor algo para ser feito. -- Marcelo Costa ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Performance
2010/1/23 Marcelo Costa marcelojsco...@gmail.com: Eu já fiz um estudo desses mas por implicações jurídicas, inclusive consultei um advogado especialista na área digital, não posso divulgar. Quero ver processarem alguém. Aliás, só isso já me indica má-fé. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3854 7191 gTalk: xmpp:leand...@jabber.org +55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT-3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm Sent from Sao Paulo, SP, Brésil ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Res: Res: Res: Res: Res: Digest pgbr-geral, volume 35, assunto 94
Caro Leonardo; Muito obrigado por responder. Seguem as minhas considerações: a - porque a operações de escrita em lote costumam custar muito caro para os logs daquela plataforma ... Você está falando de quais logs, dos arquives? É isso mesmo? Para quê importar 1 bilhão de registros com arquive? Neste caso, é só desabilitar os mesmos, ok? Também já ví uma empresa erroneamente colocando datafiles e redo logs files arquivados no mesmo disco ou utilizando a mesma I/O; aí vai ficar lerdo mesmo, não tem jeito, os arquives TEM de ser colocados em um local separado. Aproveitando: os redo log files funcionam de modo análogo ao WAL? b - O tal do Bulk Collect (verdadeiramente muito recente - 10g) Isto não te nada de recente, você está equivocado. Tal existe desde a versão 8i lançado em 1998, já completando mais de 10 anos. Também já fui programador em PL/SQL (certificado), e trabalhava com o Oracle 7.3. Para completar, tem um exemplo de utilização do bulk com a versão 8 em http://www.oracle-base.com/articles/8i/BulkBinds8i.php. c - Esse tipo de comportamento é muito comum de se encontrar em uma série de aplicações crítica naquela plataforma fechada Não entendí; comum aonde? Você poderia me enviar alguns exemplos? Que tipo de atividades são realizadas para que eu consiga simular os mesmos problemas? Você tem alguma referêmcia na web explicando isto? d - E por falar em milhares (hã?) .. isso mesmo apenas milhares de linhas é necessário recorrer aos CTAS (create table as ...) porque a operações de escrita em lote costumam custar muito caro para os logs daquela plataforma ... Olha só; se você estiver com algum problema de espaço em disco, e quiser mover alguma tabela para outro DISCO, você pode utilizar CRIATE TABLE AS a fim de efetuar uma operação mais rápida, podendo inclusive paralelizar esta operação (usar múltiplos processadores). Tal não tem NADA a ver com escritas em lote, correto? e - ...o todo poderoso ADDM que disfarça todo o problema das suas SQLs. O ADDM (Automatic Database Diagnostic Monitor) não disfarça nada, pelo contrário, ele MOSTRA PROBLEMAS relacionados à consumo de CPU, uso de memória, uso da I/O, queries, rotinas em PL/SQL, rotinas em Java, configurações do banco, contenção de objetos e concorrência, e funciona da seguinte forma: 1 - o AWR tira uma fotografia ou SNAPSHOT do banco, de tempos em tempos, e armazena as informações coletadas; 2 - o ADDM analisa os dados coletados e identifica problemas, inclusive provendo as soluções, que podem ser visualizadas no Enterprise Manager. Então, voltando ao seu exemplo das queries: se algum sistema executar uma sentença SQL mal escrita, ou com baixa performance, o ADDM identifica a query e propõe soluções, que variam desde a criação de índices até a reescrita da mesma. g - Quanto ao TPC, tenta pelo menos o H. Mas porquê? Vejamos, em http://www.tpc.org/tpch/results/tpch_perf_results.asp, verificamos publicações de testes com bancos que variam de 100 Gigas a 30 Teras, onde o EXASOL marcou o primeiro lugar em 3, o Oracle em 2 e o DB2 em 1. Aliás, no de 30 Teras só teve o Oracle; nem teve concorrência. f - é que *problemas* de performance qualquer implementação de servidor de banco de dados tem, e graças a esse problemas é que a Júlia tem o pão e leite na mesa todo Com certeza, e eu concordo muito com isso, também tenho esposa e filho. Mas o que eu vejo sempre é o seguinte: o fulano que mexe com a ferramenta A e só conhece a mesma, ou melhor, depende da mesma (caso que eu citei aquí na lista do Caché) sempre fala que esta é a melhor do mundo, é a mais rápida e etc e tal. Paciência, o cara está vendendo o peixe dele e pronto, será aquela discussão de time de futebol sem nenhum sentido e da qual não vale a pena participar. Olha só; uma empresa para a qual eu presto serviço onde o banco é PostgreSQL, e todo o mundo reclamava da performance. Só que o culpado não era o mesmo; na verdade escreveram uma aplicação bem porca, onde as entidades (cerca de 2000) foram dezenhadas tentando manter sempre uma chave única, para facilitar a programação. E o DBA da época nem sequer criou índices para as chaves estrangeiras, e não tinha estatística para nada. Resolvidos estes problemas, algumas rotinas que levavam horas - isto mesmo, horas - foram retiradas do código Java e incorporadas ao banco via funções e views, passando a rodar em minutos. Hoje, ninguém lá quer tirar o Postgres. Atenciosamente, Márcio de Figueiredo Moura e Castro De: Leonardo Cezar lhce...@gmail.com Para: Comunidade PostgreSQL Brasileira pgbr-geral@listas.postgresql.org.br Enviadas: Sexta-feira, 22 de Janeiro de 2010 19:05:28 Assunto: Re: [pgbr-geral] Res: Res: Res: Res: Digest pgbr-geral, volume 35, assunto 94 2010/1/22 MARCIO CASTRO marciomouracas...@yahoo.com.br: Colega; Eu estava tratando com outro membro da lista, quando viestes com esta falta de educação. Se vossa senhoria não
[pgbr-geral] Res: Res: Digest pgbr-geral, volume 35, assunto 94
Caro Fabiano; Primeiro entenda que: a - quem escreveu os programas foi o cliente, e não eu; b - o meu trabalho neste projeto era simplesmente orientar a equipe com relação à migração de uma base Oracle para PostgreSQL, portando o código de PL/SQL (Oracle) para PG/plSQL (PostgreSQL); c - as partes em PL/SQL nada tem de otimizado para rodar mais rápido no Oracle. Isto explicado, informo que os problemas apresentados foram no quesito performance, sempre aliados à determinados cálculos. Achando que eu estava com alguma avaria no servidor do PostgreSQL (tamanha a diferença entre os tempos de execução entre as duas plataformas) eu escreví duas funções em PL/SQL (Oracle) e em PG/plSQL (Postgres), a fim de que os integrantes da lista me auxiliassem a resolvê-lo. O código das mesmas está abaixo e, como você pode verificar, é extremamente simples. Recebí a ajuda de muitos, mas no intuito de reescrever tudo em C, o que não resolve, pois tal atividade estaria fora do escopo do projeto (são milhares de programas). Um outro colega me informou que tal demora (PG/plSQL) se daria por um problema relacionado à compilação do código no Postgres, mas não pude me aprofundar no assunto para confirmar ou não. Outro me disse que o Postgres não se presta para isso. Dito isto, faço questão de reportar que também já ouví falar desta fonte confiável, como também ouví falar do sací-pererê e da mula sem cabeça, assim como o ET de varginha. A tia de um colega meu, que está com esclerose múltipla, jura que viu o demo no quintal da casa dela. Tem um canal da TV à cabo que passa o Ghost Hunters, onde alguns indivíduos supostamente detectam fantasmas, mas eu nunca assistí. Porque será que esta fonte confiável não nos dá uma dica do que ela fez no PostgreSQL? Ela não precisa publicar nada, somente nos dizer se criou tabelas, populou as mesmas, criou índices, rodou determinados scripts e efetuou determinadas queries, as configurações do banco, e só, correto? Mas olha, se a preocupação é um processo, então é só fazer como o TPC: teoricamente, lá ninguém compara nada, mas o número de transações está lá, as máquinas também, assim como os valores pagos e os métodos para efetuar tal estudo. 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: Wolak Sistemas - Fabiano Machado Dias fabi...@wolaksistemas.com.br Para: Comunidade PostgreSQL Brasileira pgbr-geral@listas.postgresql.org.br Enviadas: Sábado, 23 de Janeiro de 2010 13:20:13 Assunto: Re: [pgbr-geral] Res: Digest pgbr-geral, volume 35, assunto 94 Se o seu sistema já estava escrito em Oracle e você apenas migrou para o Postgresql como você queria que tivesse o mesmo desempenho? Você teria que rever a sua escrita porque com certeza o código que você escreveu foi otimizado para rodar no Oracle, para fazer a migração você deveria ter o mesmo cuidado e analisar o código que foi portado para o Postgresql. Também já ouvi de fonte confiável que em testes realizados comparando os dois bandos o PG chegou a ser até 50% mais rápido que o Oracle, mas é claro que esse teste não foi publicado e nem será. Abraço, Fabiano Machado Dias Euler Taveira de Oliveira escreveu: 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).
[pgbr-geral] Res: Performance
André: Concordo com você. Com relação á publicação, tal nem se faz necessário. Podemos pontuar com alguns testes aquí mesmo na lista, sem relacionar dados ou bancos, mas apenas divulgando, da forma mais simples possível, a metodologia utilizada. Aliás, podemos começar com um tópico do tipo Como Verificar o Desempenho do Seu Servidor Postgres, tomando o cuidado para que estes testes possam ser feitos em qualquer outra plataforma, e sem citar as mesmas. O que é que você acha? De: Andre Fernandes fernandes.an...@gmail.com Para: Comunidade PostgreSQL Brasileira pgbr-geral@listas.postgresql.org.br Enviadas: Sábado, 23 de Janeiro de 2010 17:12:42 Assunto: [pgbr-geral] Performance Boa tarde, Há uma discussão sobre desempenho de Oracle vs. PostgreSQL ocorrendo em outro tópico, mas estamos indo em uma discussão complicada e com argumentos complicados de ambos os lados. Honestamente, Oracle é um ótimo banco, assim como é o PostgreSQL (que é meu banco de dados predileto). Se vamos fazer um comparativo entre ambos, precisamos primeiro fazer um modelo coerente de testes e executá-los. E também precisamos levar em consideração o design e a função de cada linguagem de cada banco de dados. Eu gostaria muito de ver um comparativo bem montado, mas não tenho hardware nem tempo necessário para executar o mesmo. Por experiência própria, imagino ver um desempenho próximo entre os dois (obviamente ambos os bancos bem configurados), sendo que um brilharia mais em alguns pontos e o outro em outros. Já fui DBA de Oracle (na versão 8) e sou hoje de PostgreSQL (desde a versão 8.0), em nenhum dos dois casos descepcionei-me. Na realidade, ambos os bancos continuam a me surpreender regularmente. Se houver quem deseje elaborar um estudo desses, acho que seria de grande valia. Contudo, peço encarecidamente que não façamos afirmações amadoras do tipo Oracle é melhor que PostgreSQL ou PostgreSQL é melhor de Oracle sem dados reais ou apenas baseados em um caso específico, a não ser em conversas de bar. Um estudo bem montado poderia inclusive diminuir a incidência de afirmações amadoras como essas. Abraços, -- André de Camargo Fernandes PS: Não sei se seria possível fazer um estudo desses e publicar pois não sei se a Oracle permitiria a divulgação do mesmo (desconheço a licensa da Oracle, não sei se tem alguma cláusula referente a isso). Veja quais são os assuntos do momento no Yahoo! +Buscados http://br.maisbuscados.yahoo.com___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Res: Performance
Não, não podemos divulgar nada sem o consentimento da Oracle, mas podemos iniciar um estudo aquí de nome Como verificar a performance do seu servidor PostgreSQL´, de forma à que possamos testar o mesmo em outro ambiente, por conta própria. De: fabi...@wolaksistemas.com.br fabi...@wolaksistemas.com.br Para: Comunidade PostgreSQL Brasileira pgbr-geral@listas.postgresql.org.br Enviadas: Sábado, 23 de Janeiro de 2010 18:06:21 Assunto: Re: [pgbr-geral] Performance Concordo, no entanto se você foi DBA Oracle deveria saber que o tal estudo não poderá ser divulgado e talvez nem realizado sem a autorização da Oracle! Abraço, Fabiano Machado Dias Boa tarde, Há uma discussão sobre desempenho de Oracle vs. PostgreSQL ocorrendo em outro tópico, mas estamos indo em uma discussão complicada e com argumentos complicados de ambos os lados. Honestamente, Oracle é um ótimo banco, assim como é o PostgreSQL (que é meu banco de dados predileto). Se vamos fazer um comparativo entre ambos, precisamos primeiro fazer um modelo coerente de testes e executá-los. E também precisamos levar em consideração o design e a função de cada linguagem de cada banco de dados. Eu gostaria muito de ver um comparativo bem montado, mas não tenho hardware nem tempo necessário para executar o mesmo. Por experiência própria, imagino ver um desempenho próximo entre os dois (obviamente ambos os bancos bem configurados), sendo que um brilharia mais em alguns pontos e o outro em outros. Já fui DBA de Oracle (na versão 8) e sou hoje de PostgreSQL (desde a versão 8.0), em nenhum dos dois casos descepcionei-me. Na realidade, ambos os bancos continuam a me surpreender regularmente. Se houver quem deseje elaborar um estudo desses, acho que seria de grande valia. Contudo, peço encarecidamente que não façamos afirmações amadoras do tipo Oracle é melhor que PostgreSQL ou PostgreSQL é melhor de Oracle sem dados reais ou apenas baseados em um caso específico, a não ser em conversas de bar. Um estudo bem montado poderia inclusive diminuir a incidência de afirmações amadoras como essas. Abraços, -- André de Camargo Fernandes PS: Não sei se seria possível fazer um estudo desses e publicar pois não sei se a Oracle permitiria a divulgação do mesmo (desconheço a licensa da Oracle, não sei se tem alguma cláusula referente a isso). ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br 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 pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Res: Performance
Comparativos podem ser divulgados desde que com a permissão dos devidos fabricantes, tanto é que existe o TPC. Até o MySQL está lá! Agora; podemos efetuar os nossos próprios testes, onde você pode divulgar um determinado modelo de banco, uma estrutura, queries ou quaisquer outras coisas, e fica à critério de cada um efetuar o mesmo em outras bases. Aliás, o seu estudo é baseado em quê? Você não pode mandar para mim em PVT não? De: Marcelo Costa marcelojsco...@gmail.com Para: Comunidade PostgreSQL Brasileira pgbr-geral@listas.postgresql.org.br Enviadas: Sábado, 23 de Janeiro de 2010 19:53:52 Assunto: Re: [pgbr-geral] Performance Olá André 2010/1/23 Andre Fernandes fernandes.an...@gmail.com Em 23 de janeiro de 2010 18:06, fabi...@wolaksistemas.com.br escreveu: Concordo, no entanto se você foi DBA Oracle deveria saber que o tal estudo não poderá ser divulgado e talvez nem realizado sem a autorização da Oracle! Abraço, Fabiano Machado Dias Como quando fui DBA de Oracle não me preocupava com isso, não tinha sequer olhado para esse aspecto jurídico. Falha minha (por isso disse que não sabia se era possível). Aliás, isso foi antes de eu conhecer o postgreSQL (na época conhecia apenas Oracle, MySQL e MS SQL Server). Eu já fiz um estudo desses mas por implicações jurídicas, inclusive consultei um advogado especialista na área digital, não posso divulgar. Eu gerencio um banco de dados com 2.5 T em PostgreSQL que migrei de um Oracle 1'0g. Conheços outros testes comparativos que existem, mas também que não podem ser divulgados. Em minha opnião nunca haverá um dia em que um comparativo desses poderá ser divulgado. Até o pessoal do time internacional nunca fez isso (pelo menos não tenho conhecimento). Assim como muitos, tenho minha experiência com PostgreSQL desde a versão 7.3 e realizei algumas migrações de outros SGDBs para ele. Nunca existiu algum cliente que tenha me pedido a migração e que tenha reclamado depois. No máximo, devido a resistencia, o que ocorreu foi a substituição do DBA mesmo após sua capacitação devida. Eu negocio tudo. Infelizmente algumas pessoas não aceitam migrar de uma tecnologia para outra e se mantem resistentes mesmo que quem esteja pagando informe do desejo da migração. Dessa discussão toda o que posso afirmar é que cada caso é um caso, se a PL/pgSQL não me atende eu procuro sempre uma outra forma de implementar e conseguir a performance que preciso. Meu time implementa PL ´s em várias linguagens, PL/pgSQL, PL/PHP, PL/Perl(Perl faz coisas bizarras :-P, mas faz), até PL/Java. Sei que nem sempre há como pagar um profissional que consiga fazer isso mas quando precisamos, procuramos aprender e implementar. Tem dado certo nos últimos 2 anos. Mas de qualquer forma, muito boa sua atitude de pelo menos propor algo para ser feito. -- Marcelo Costa Veja quais são os assuntos do momento no Yahoo! +Buscados http://br.maisbuscados.yahoo.com___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Res: Performance
Você pode encontrar um comparativo publicado em: http://www-css.fnal.gov/dsg/external/freeware/mysql-vs-pgsql.html De: Leandro DUTRA leandro.gfc.du...@gmail.com Para: Comunidade PostgreSQL Brasileira pgbr-geral@listas.postgresql.org.br Enviadas: Sábado, 23 de Janeiro de 2010 20:15:05 Assunto: Re: [pgbr-geral] Performance 2010/1/23 Marcelo Costa marcelojsco...@gmail.com: Eu já fiz um estudo desses mas por implicações jurídicas, inclusive consultei um advogado especialista na área digital, não posso divulgar. Quero ver processarem alguém. Aliás, só isso já me indica má-fé. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3854 7191 gTalk: xmpp:leand...@jabber.org +55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT-3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm Sent from Sao Paulo, SP, Brésil ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br 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 pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Res: Performance
Leandro; seu advogado se baseou em quais leis? Estas leis são internacionais? Quais artigos? E neste caso, porquê o pessoal do TPC não é processado? Mas não precisa publicar nada não; manda prá mim em PVT só o que você fez no Postgres, ok? Desta forma, fica a meu critério testar o mesmo em qualquer outra plataforma, e portanto, tú estarás livre de quaisquer processos, correto? Simples, não? No aguardo, Márcio de Figueiredo Moura e Castro De: Leandro DUTRA leandro.gfc.du...@gmail.com Para: Comunidade PostgreSQL Brasileira pgbr-geral@listas.postgresql.org.br Enviadas: Sábado, 23 de Janeiro de 2010 20:15:05 Assunto: Re: [pgbr-geral] Performance 2010/1/23 Marcelo Costa marcelojsco...@gmail.com: Eu já fiz um estudo desses mas por implicações jurídicas, inclusive consultei um advogado especialista na área digital, não posso divulgar. Quero ver processarem alguém. Aliás, só isso já me indica má-fé. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3854 7191 gTalk: xmpp:leand...@jabber.org +55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT-3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm Sent from Sao Paulo, SP, Brésil ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br 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 pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Comparação Postgres versus Outros ERA: Re: Res: Res: Res: Res: Res: D igest pgbr-geral, volume 35, assunto 94
Srs, Essa lista tem poucos emails enviados por dia, por isso IMO é desnecessário utilizar o modo digest, além da maioria dos MUAs possuir recursos de filtragem de mensagens, etiquetagem, redirectionamentos, ca. Mesmo assim todo usuário tem o direito de escolher qual modo convém para recebimento de e-mails. Mas a quantidade de usuários respondendo mensagem DIGEST vem aumentando significativamente, o que é ruim para indexação e sobrecarga dos nossos servidores. Portanto, venho encarecidamente pedir a todos que _não_respondam_ mensagens em modo DIGEST. 2010/1/23 MARCIO CASTRO marciomouracas...@yahoo.com.br: a - porque a operações de escrita em lote costumam custar muito caro para os logs daquela plataforma ... Márcio, a forma como voce edita as mensagens confude e as vezes altera completamente o contexto das frases. Fica até complicado de entender o que nós mesmo falamos em outras mensagens. Dê preferência de utilizar o modelo de respostas entre linhas (/inline replying/)[1]. Você está falando de quais logs, dos arquives? É isso mesmo? Para quê importar 1 bilhão de registros com arquive? Neste caso, é só desabilitar os mesmos, ok? Não estou falando de *arCHives* e nem falei de um bilhão de registros. Repare que em mnha mensagem original eu citei os processos DBW e LGW que são responsáveis pela atualização dos data files e REDO, mas não citei o nome do processo ARC. AFAIR, não é possível desabilitar os logs de transação de uma tabela para operações de exclusão, mas é possível criar uma tabela nova com operações de LOG reduzidas (cláusula NO LOGGING) e utilizar /hints/ para induzir o otimizador a utilizar /direct-path/ para inclusão de registros na tabela (CTAS). Note que utilizar a abordagem do CTAS sem LOG faz com que a fragmentação do segmento aumente, pois novos blocos serão criados acima da HWM – marca d'agua superior (tradução livre e tosca). Em seguida voce precisaria reorganizar (SHRINK) e isso gera ônus de performance de qualquer jeito. Aproveitando: os redo log files funcionam de modo análogo ao WAL? Médio. O redo utiliza o protocolo de escrita prévia [2] e da mesma forma o WAL do postgres implementa o protocolo de mesmo nome, porém existem algumas diferenças: - A operação de atualização do REDO do Oracle é síncrona enquanto que no postgres podemos configurar isto. - No PostgreSQL não podemos definir tamanho de segmentos de log nem adicionar explicitamente novos logs (checkpoint+pg_switch_log não faz isto!), porém podemos aumentar na compilação o tamanho de todos segmentos. - O Or**le trabalha com grupos de arquivos de logs espelhados de forma que *todos* os arquivos de um grupo precisam ter sido gravados no disco (checkpoint) para ele criar um novo grupo. - O arquivo de controle (scn) do O**le pode ser multiplexado enquanto que pg_control do postgres não pode (eu já fiz e funciona, por que não pode??) - Cada segmento de log do postgres possue um nome diferente e o mesmo nome nunca será reaproveitado nem mesmo numa situação de recuperação, onde o timeline (se não me engano quinto digito do nome do arquivo) iria mudar. No Or*cle os segmentos pertencentes a um mesmo grupo são reciclados (ou arquivados) e reaproveitados após um checkpoint. Ah! Deve ter mais coisa aí, mas agora não lembro. b - O tal do Bulk Collect (verdadeiramente muito recente - 10g) Isto não te nada de recente, você está equivocado. Tal existe desde a versão 8i lançado em 1998, já completando mais de 10 anos. Também já fui programador em PL/SQL (certificado), e trabalhava com o Oracle 7.3. Para completar, tem um exemplo de utilização do bulk com a versão 8 em http://www.oracle-base.com/articles/8i/BulkBinds8i.php. Desculpe por isto, o que eu quis dizer foi utilizando índices sobre coleções, se não me engano INDEX OF da cláusula FORALL. Se este também existia no 8i é porque eu realmente tenho olhado muito pouco para o PL/SQL mesmo nos últimos anos. c - Esse tipo de comportamento é muito comum de se encontrar em uma série de aplicações crítica naquela plataforma fechada Não entendí; comum aonde? Você poderia me enviar alguns exemplos? Que tipo de atividades são realizadas para que eu consiga simular os mesmos problemas? Você tem alguma referêmcia na web explicando isto? Referência de problemas com atualização em massa de dados? Sim é *bem* comum, vide discussões no asktom[3]. Busque por exclusão massiva, bulk load, forall .. d - E por falar em milhares (hã?) .. isso mesmo apenas milhares de linhas é necessário recorrer aos CTAS (create table as ...) porque a operações de escrita em lote costumam custar muito caro para os logs daquela plataforma ... Olha só; se você estiver com algum problema de espaço em disco, e quiser mover alguma tabela para outro DISCO, você pode utilizar CRIATE TABLE AS a fim de efetuar uma operação mais rápida, podendo inclusive paralelizar esta operação (usar múltiplos processadores). Tal não tem NADA a ver com escritas em lote, correto? É ... de
Re: [pgbr-geral] Res: Performance
2010/1/24 MARCIO CASTRO marciomouracas...@yahoo.com.br: Você pode encontrar um comparativo publicado em: http://www-css.fnal.gov/dsg/external/freeware/mysql-vs-pgsql.html O que voce não pode fazer, segundo a licença da Oracle é comparação de performance. Quanto a funcionalidades você pode citar o produto da Oracle. Alias, essa comparação é inútil de tão desatualizada e vaga. -Leo -- Leonardo Cezar http://www.aslid.org.br http://postgreslogia.wordpress.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
