A parte prazerosa do negócio realmente é a otimização, sendo assim seguimos um princípio que para otimizar uma consulta podemos utilizar desde verificação de índices, mudanças em sqls de consulta, refatoração para desempenho (mudanças no modelo), aprimoramento de novas tabelas com dados sumarizados e também particionamento quando temos uma grande massa de dados. Uma outra técnica utilizada também é separar banco de consulta do banco de movimentação (transacional), até o modelo do banco de consulta passa a ser no formato *Star Schema ou **SNOW FLAKE **que é utilizado no conceito de DataWarehouse (DW). * * * * * ***Star Schema http://pt.wikipedia.org/wiki/Esquema_estrela*
Mas tudo isso deve ser valido, até mesmo para o molho não sair mais caro que a carne, ou seja, você deve aplicar alguma técnica que satisfaça a sua aplicação ou até mesmo, conviver com o problema de otimização (em alguns casos), pois o custo de tornar uma aplicação mais rápida pode ser tão alto que se torna inviável. Att Rodrigo Della Justina * * * <http://pt.wikipedia.org/wiki/Esquema_estrela> * Em 15 de abril de 2011 20:24, Tiago Adami <adam...@gmail.com> escreveu: > Em 15 de abril de 2011 10:18, Fábio Gibon - Comex System > <gi...@comexsystem.com.br> escreveu: > > Olá pessoal, > > analisando as views de stat conseguimos identificar índices que > não > > são utilizados, porém isto ainda não nos diz que esta "não utilização" é > > pela aplicação não estar fazendo uso de cláusulas que possam ser > atendidas > > pelo índice ou pela tabela ser pequena e o otimizador optar por um table > > scan. Há como eu diferenciar isto em algum local do dicionário de dados > do > > banco? > > > > * provisoriamente adotei um valor x de registros como sendo > > permissível/aceitável o table scan, então se o acesso sequencial retornar > > mais que este valor eu já "fico de olho" para ver se não tem problema de > SQL > > mal escrito/erro de modelagem ou regra de negócio "torta". > > > > Não conheço a fundo o código-fonte do PostgreSQL - mesmo porque > entendo muito pouco de C - mas pelo comportamento que vejo em outros > bancos de dados, quando uma tabela está quase totalmente em cache e > você cria um SQL SELECT que traz quase todos os registros, o > otimizador é inteligente o suficiente para saber que um Table Scan é a > melhor opção. > > Eu considero a parte de otimização de consultas a parte mais divertida > e prazerosa do trabalho de um DBA. Muitas vezes - quase sempre - é > necessário reescrever a consulta para melhorar o tempo de resposta, > outras vezes você modifica um ou outro índice, e por aí vai. Existem > 1001 maneiras de otimização... invente uma! > > -- > TIAGO J. ADAMI > http://www.adamiworks.com > _______________________________________________ > 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
