Revision as of 20:10, 9 March 2013 by Telles (Talk | contribs)
Jump to: navigation, search	Tradução do texto original de Josh Berkus publicado em 28/11/2006 e 29/11/2006.
Projeto de aplicações para performance no PostgreSQL Escrevendo regras de consultas
Dica 1: Nunca use várias consultas pequenas quando uma grande consulta pode fazer o trabalho. É comum em aplicações MySQL lidar com joins no código da aplicação, ou seja, consultando o ID de um registro relacionado e então iterando através dos registros filhos com aquele ID manualmente. Isto pode resultar em rodar centenas de consultas por tela de interface com o usuário. Cada uma destas consultas levam 2 a 6 milissegundos por rodada, o que significa que se você executar cerca de 1000 consultas, neste ponto você estárá perdendo de 3 a 5 segundos. Comparativamente, solicitando estes registros numa única consulta levará apenas algumas centenas de milissegundos, economizando cerca de 80% do tempo.
Dica 2: Agrupe vários pequenos UPDATEs, INSERTs ou DELETEs em um único comando ou, se não for possível, em uma longa transação. Antes, a falta de subselects nas versões anteriores do MySQL fizeram com que os desenvolvedores de aplicação projetassem seus comandos de modificação de dados (DML) da mesma forma que as junções em middleware. Esta é uma má idéia para o PostgreSQL. Ao invés, você irá tirar vantagem de subselects e joins no seu comando UPDATE, INSERT, e DELETE para tentar realizar modificações em lote com um único comando. Isto reduz o tempo da rodada e o overhead da transação.
Dica 3: Considere realizar cargas em lotes ao invés de INSERTs seriais. O PostgreSQL prove um mecanismo de carga em lote chamado COPY, que pode pegar uma entrada de um arquivo ou pipe delimitado por tabulações ou CSV. Quando o COPY pode ser usado no lugar de centenas de INSERTs, ele pode cortar o tempo de execução em até 75%.
Dica 4: O DELETE é caro É comum para um desenvolvedor de aplicação pensar que o comando DELETE é praticamente não tem custo. Você está apenas desligando alguns nós, correto? Errado. SGDBs não são sistemas de arquivo; quando você apaga uma linha, índices precisam ser atualizados, o espaço liberado precisa ser limpo, fazendo a exclusão de fato mais cara que a inserção. Assim, aplicações que habitualmente apagam todas as linhas de detalhe e repõe elas com novas toda vez que é realizada qualquer alteração estão economizando esforço no lado da aplicação e empurrando este dentro do banco de dados. Quando possível, isto deve ser substituído pela substituição mais discriminada das linhas, como atualizar apenas as linhas modificadas.
Dica 5: Utilize o PREPARE/EXECUTE para iterações em consultas Algumas vezes, mesmo tentando consolidar iterações de consultas semelhantes em um comando mais longo, nem sempre isto é possível de estruturar na sua aplicação. É para isto que o PREPARE ... EXECUTE serve; ele permite que o motor do banco de dados pule o analizador de sintaxe e o planejador para cada iteração da consulta. Por exemplo:
query_handle = query('SELECT * FROM TABLE WHERE id = ?')(parameter_type = INTEGER)
Dica 6: Use pool de conexões efetivamente Para uma aplicação web, você irá perceber que até 50% do seu potencial de performance pode ser controlado através do uso, e configuração apropriada de um pool de conexões. Isto é porque criar e destruir conexões no banco de dados leva um tempo significativo no sistema, e um excesso de conexões inativas continuarão a requerer RAM e recursos do sistema.
Notas de Copyright Texto originalmente traduzido por Fábio Telles Rodriguez <fabio.telles@gmail.com> em http://savepoint.blog.br/dicas-de-performance-em-aplicacoes-com-postgresql/
Tradução livre do texto: "PostgreSQL Application Performance Tips, Part 1" publicado por Josh Berkus em 28/11/2006 em http://blogs.ittoolbox.com/database/soup/archives/postgresql-application-performance-tips-part-1-13172
e "PostgreSQL Application Performance Tips, Part 2" publicado por Josh Berkus em 29/11/2006 em http://blogs.ittoolbox.com/database/soup/archives/postgresql-application-performance-tips-part-2-13194