[firebase-br] RES: otimização, performance no Firebird como fazer nos arquivos de configuração?

[Carlos H. Cantu]

Com certeza, select count em tabelas grandes deve ser evitado.

Como o select não tem JOIN, nem WHERE, nem order by, nenhum indice
será usado mesmo, pois nesse um natural scan é mais vantajoso.

[]s
Carlos H. Cantu
www.FireBase.com.br - www.firebirdnews.org
www.warmboot.com.br - blog.firebase.com.br

APB> Cantu,
APB> O teste que fiz é sobre querys simples para comparar os bancos e tomar uma
APB> decisão sobre os SGBD aqui. 
APB> Eu fiz o SET STATISTICS e o backup/restore, mas a plan usada pelo otimizador
APB> foi a NATURAL (sem índice) eu até criei algumas plan com uso de índice mas
APB> não adiantou.
APB> Apenas mudaram alguns milisegundos.
APB> Pesquisando mais no IBexpert e no Firebasemonitor vi que a consulta para
APB> mostrar os dados é rápida, coisa de milisegundos.

APB> SELECT FIRST 12 SKIP 0 CODIGO, CAMPOVARCHAR from NEW_TABLE

APB> O problema é que o framework que estou usando faz um select count(*) para
APB> paginar os resultados na web.

APB> select count(*) from NEW_TABLE

APB> Achei isto aqui sobre o select count(*)
APB> http://www.firebirdfaq.org/faq5/
APB> http://wiki.postgresql.org/wiki/Slow_Counting
APB> E realmente monitorando a base vi que ele é o gargalo tanto no Firebird
APB> quanto no Postgresql
APB> Como o Framework do Scriptcase é fechado, não há muita coisa que eu possa
APB> fazer para melhorar a situação neste teste em específico.
APB> Mas fica o motivo das diferenças de tempo.
APB> Obrigado pela resposta e pelo Firebase Monitor.

APB> --
APB> Alexandre Pereira Bühler
APB> Linux User: 397.546

APB> Simão &  Bühler Ltda (Infobrindes)
APB> http://www.simaoebuhler.com.br
APB> alexandre em simaoebuhler.com.br
APB> Telefone: (41) 3039-5428

APB> Infobrindes (Simão &  Bühler Ltda)
APB> Brindes e material promocional.
APB> http://www.infobrindes.com.br
APB> alexandre em infobrindes.com.br
APB> Telefone: (41) 3082-8667