[firebase-br] Firebird 3.0 muito lento com Distinct

[luapfirebird em yahoo.com.br]

 Nosso amigo fico muito grato pela grandiosa explicação.
Realmente a conversar é mais em baixo em fazer esses tipo de analizes que estou fazendo.
O interessante que quando não usa Distinct o FB ganha do SQLServer fica páreo o PostgresSQL
Pelo que percebi usando Indices o SQLServer não é muito lá essas coisas pois na maioria dos testes que fiz ele perde para o FB e para o PostgresSQL  por pouca diferença mais perde.
Gora uma coisa Eu lhe digo estou muito feliz com o FB  pelos recursos que tem e pela velocidade,  Eu tinha medo de ele perder para esses banco mais consagrados.
E como ele pode ter uma tamanho exagerado de 32TB  eu posso ficar tranquilo pelo resto da vida rs rs rs rs rs rs rs rs rs rs rs 
Quando ele chegar nesse tamanho ai quem sabe eu precisarei de um Cassandra ou MongoDB  igual o Google e o Facebook   partir completa insanidade e Loucura no NoSQL.


    Em quinta-feira, 5 de abril de 2018 10:19:52 BRT, Gladiston Santana <gladiston em vidy.com.br> escreveu:  
 
 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.
>
>
>
______________________________________________
FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
Para saber como gerenciar/excluir seu cadastro na lista, use: http://www.firebase.com.br/fb/artigo.php?id=1107
Para consultar mensagens antigas: http://www.firebase.com.br/pesquisa_lista.html