[firebase-br] Firebird 3.0 muito lento com Distinct

[Gladiston Santana]

O MSSQL cria indices e faz o prepare automaticamente quando suas
estatisticas percebem a repetição da query.
Até otimizam sua querie na preparação, pois as vezes a ordem dos elementos
where podem favorecer um indice mais promissor, assim, a cada execução é
guardada um valor de custo da operação daquele plano de execução, e na
próxima execução com um plano diferente, ele compara com o anterior e se
perceber que o novo é melhor que o anterior então passará a usar o novo,
ele repetirá isso sistematicamente até determinar que o plano escolhido foi
absoluto e tem o melhor custo de operação. Por essa razão, nunca dropamos o
banco para cria-lo de novo, como alguns fazem no FB, pois isso apagaria as
estatisticas e teria tudo começar novamnete.  O MSSQL faz isso desde a
versão 6.0 em 1997 quando rodava no NT (malditos lock por tabela).
Hoje quando se instala o MSSQL num servidor, ele assume que o sistema é
dedicado, versões antigas você podia ajustar isso e até quanta memória ele
iria usar, mas nas versões posteriores parece que isso não tá mais no
wizard, talvez no sp_configure(algo mais escondido), então o BD terá sempre
prioridade sobre outros serviços e instancias.
Então para ter uma comparação justa você teria de criar 3 servidores
virtuais, cada qual com o seu banco.
Algo que notará é que o MSSQL não é muito eficiente com pouca memória, como
ele se ajusta para um sistema dedicado, ele espera usar todos os recursos
do sistema. O Windows tem um QoS para serviços, e o MSSQL tem prioridade
perdendo apenas para o próprio Windows.
Mas tudo isso que falei é na versão paga, a versão gratuita é ilusão, pois
não faz quase nada de grandioso senão como um demo para comprar a versão
maior quando o dono perceber que alguma coisa tá errada depois de alguns
gigas - há algumas travas artificiais onde a versão express ficará lenta
mesmo em supercomputadores. Algumas softwarehouses avisam o cliente quando
ele optar por esse banco de dados, enquanto outras preferem a conta a
qualquer custo e isso se conserta $$$ depois.

Também gostaria de lembrar que o FB não vai criar índices automáticos, se
pretende usar agregadores é bom observar se tem os índices apropriados e se
tais agregadores serão tão usados assim para justificar sua criação, pois
mais índices prejudicam a atualização em detrimento de maior velocidade na
pesquisa.

Na comparação entre bancos é bom se acostumar com as nuancias de cada um
deles, há banco que tem alguma IA e sabe intervir como usar o índice de
forma invertida, mudar a ordem de precedência dos where, etc... mas outros
bancos podem não saber fazer isso ou falhar. Então é bom o programador
escrever a query da maneira mais facil para o banco ler. Por isso comparar
o mesma SQL em todos os bancos só é valido quando foram logicamente bem
escritos a ponto de qualquer BD saber interpretá-lo corretamente. Por
exemplo, primeiro WHERE categoria=xxxx, depois and (data between xxxx and
yyyyy), uma ordem diferente poderia apresentar problemas de performance
entre os bancos na comparação quando a IA do banco consertasse a falha e
outro não.
Os bancos de dados usam basicamente o mesmo algorítimo de consultas em
índices (btree), então faz sentido que as pesquisas em bancos sejam bem
similares, a diferença está em minimizar o I/O e tem bancos que faz isso
melhor que o outro.

[]´s

Em 4 de abril de 2018 12:16, luapfirebird em yahoo.com.br <
luapfirebird em yahoo.com.br> escreveu:

> Pessoal como eu já tinha mencionado antes fiz vários testes com o
> FirebirdSQL e o PostgresSQL Agora por ultimo testei o SQL Server.
> todos os 3 Bancos tem os mesmo numero de registros, com mesmos índices e
> feito reindexação de índices em cada um dos bancos usando ferramentas
> especificas dos mesmos.
> No incio dos meus testes errei por estar dando Fetch All no FB e no
> PostgresSQL dar apenas Fetchapôs essa correção percebi que o FB é páreo
> para o PostgresSQL em varias consultas inclusive ganha em muitas delas.
> Porém quando o Assunto é Distinct a coisa muda completamente de figura.
> o FirebirdSQL é extremamente lento usando Distinct  sei que vão dizer que
> ele terá que checar todas as linhas porém o detalhe é fiz o mesmo testecom
> a mesmo SQL nos 3 bancos o resultado é muito desanimador para o FB.no
> PostgresSQL usando Distinct o tempo aumenta 60% em media  ou seja uma
> consulta de demora 1 Segundo vai para 1.6agora no Firebird a coisa fica
> feia pois de 0.9 sec  ou seja ele é mais rápido sem Distinct que o
> PostgresSQL  porém com Distinct leva 5.5 sec
> Já no SQL Server é lindo de se ver pois para ele tanto faz Distinct ou não
> o tempo é o mesmo,  ele consegue fazer uso completo do Índice tanto que o
> PLAN não muda em nada.
>  Acredito que o Core developer do firebird deveria analisar melhor essa
> situação pois correr linhas sem índices para o FB é muito custoso,  e para
> outros bancos isso é bem mais rápido que o FB.
>
>
>