2010/1/25 MARCIO CASTRO <[email protected]> > > > De qualquer forma, gostaria de realizar os meus próprios testes aquí, e da > melhor forma possível, a fim de descobrir o porquê da diferença de > performance do PostgreSQL versus Oracle. >
Essa é uma boa pergunta, há algumas formas. Acho que um dos principais requisitos é a leitura e a escrita em tabelas, correto? Então eu faria um teste criando uma tabela parecida com alguma tabela que uses (de preferência uma tabela com muitos diferentes campos, chave primária e também índices), por exemplo, acrescentaria a esta alguns milhares ou mesmo milhões de dados randômicos (massa ou carga de testes). Logo em seguida faria algumas queries de obtenção de dados: select simples (sem cláusula where), um select com clausula where que use a chave primária, um select que use um campo indexado que não seja chave primária e alguns testes que tenham clausulas where com condições binárias (usando índices, de preferência). Logo após, criaria uma segunda tabela que tenha um campo como chave estrangeira para a primeira tabela. Novamente faria uma carga e então uma sequência de selects, mas desta vez usando a união da duas tabelas. Primeiro faria sem criar um índice no campo da chave estrangeira e, depois, criaria o índice e refaria todos os selects anteriores. Até aqui teríamos testes simples de select. Para um teste um pouquinho melhor, acrescentaria testes que usassem agrupamentos (como count() e sum()), e logo após queries recursivas, além de ordenação. Isso já daria uma massa boa de testes para comparar desempenho em selects com poucas tabelas em ambos os bancos. Também faria em seguida testes de inserção e de criação de tabelas usando CREATE TABLE AS SELECT. Os testes de inserção poderiam ser com insert simples e inserts usando selects em alguns campos. Até aqui terias um teste de inserts, selects e create table as select. Se quiseres, um bom teste também seria fazer algo semelhante com updates. Por fim, faria testes de acessos a tabelas com PL/pgSQL e PL/SQL. Um bom teste inicial poderia ser um select bobo e a cada interação no mesmo fazer alguma coisa com os dados, para então retorná-los. Outro teste poderia ser o de ler os dados de uma tabela (com alguma cláusula where, por exemplo) e no loop atualizar outra tabela, ou mesmo inserir em outra tabela alguns dos campos encontrados. E quaisquer outros testes que dependam de acesso a dados e/ou atualização e/ou atualização de dados em tabelas (lembre-se de que PL/pgSQL tem função primária de acesso a dados, assim cálculos puros, sem acesso a dados (como fatoriais, por exemplo) não seriam uma boa amostragem do uso de functions em postgreSQL com PL/pgSQL pois não é algo para o qual foi criada. Acho que com um teste assim terias algo mais interessante e melhor para comparar ambos os bancos e descobrir o melhor de cada um. Contudo um teste assim demanda um pouquinho de trabalho, infelizmente. Quanto mais casos distintos conseguires fazer, mais casos distintos conseguirias averiguar. Como disse antes, não descepcionei-me até hoje com nenhum dos dois bancos, são muito bons. Não sei se esse modelo (bem rascunhado ainda) pode ajudar-te, espero que sim. Qualquer coisa, podemos desenhá-lo melhor (escrevi-o correndo agora). > > Dito isso, quais testes eu DEVERIA aplicar no PostgreSQL a fim de me > certificar que a performance está ok ou não, ou se os parãmetros de > configuração estão mal configurados, ou se há algum outro problema não > detectado? > > Não existe uma regra fixa de como saber se está bem configurado. Parte da configuração tem de ser testada e verificada na prática, não existe uma fórmula matemática para achar a configuração perfeita, infelizmente. Um bom método seria verificar se as consultas estão no tempo esperado ou se estão muito distantes do esperado. Em geral, consultas costumam ter tempo de resposta semelhante às equivalentes do Oracle, que imagino teres uma maior vivência, assim podes usar esse tempo como referência. Pequenas diferenças não são problema, mas distâncias grandes entre os desempenhos pode indicar má configuração, falta ou excesso de índices ou mesmo consulta mal escrita. Abraços e boa sorte, -- André de Camargo Fernandes
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
