[firebase-br] Função com melhor desempenho: Max ou First 1

Danilo danrgomes em gmail.com
Seg Jan 20 14:26:40 -03 2020


Olá

Muito legal sua explicação Cantu ...entendi .. agora mais por curiosidade
.. existe documentação que explica esse funcionamento? Ou só se tornando um
colaborador Dev Firebird para ter acesso ao fonte ?

Em seg., 20 de jan. de 2020 às 11:00, Carlos H. Cantu <
listas em warmboot.com.br> escreveu:

> Cada SGBD tem suas próprias implementações em relação a como cada
> processo é feito, portanto, nem sempre a teoria válida para um é
> válida para o outro. Tem que entender os "internos" de cada SGBD pra
> saber como ele lida com cada situação.
>
> Nem sempre o order by exige sort. Se existir um índice, o FB irá usar
> o índice sempre que possível para não ter que fazer sort. Mesma coisa
> em relação ao First.
>
> Outro exemplo: o count no FB exigirá que o FB visite cada registro
> para saber se ele está visível para a transação que está fazendo o
> count (devido a arquitetura de versioning).
>
> []s
> Carlos H. Cantu
> eBook Guia de Migração para o FB 3 - www.firebase.com.br/guiafb3.php
> www.FireBase.com.br - www.firebirdnews.org - blog.firebase.com.br
>
> D> Olá
>
> D> Olha .. se pensar na teoria .. um order by vai sempre obrigar o SGBD a
> D> utilizar uma algoritmo de ordenação no seu SGBD, o que sempre é uma
> rotina
> D> mais "lenta" e ainda até onde eu sei, o first, simplesmente não exibe os
> D> outros registros, mas ele tem que saber qual é o primeiro, assim ele
> D> carrega os outros mas não exibe. Já o count, desde que faça em cima
> somente
> D> somente de um campo, por mais que ele seja indexado, ñão haverá
> D> "movimentação de posição de dados" para exibição.
> D> Assim pensando lá na disciplina de Estrutura de Dados do seu professor
> D> chato, tecnicamente o count deve ser mais rápido. Ahh mais uma coisa..
> para
> D> fazer sort deve haver um count para ir ornando.
>
> D> Danilo
>
> D> Em sex., 10 de jan. de 2020 às 16:52, Carlos H. Cantu <
> D> listas em warmboot.com.br> escreveu:
>
> >> Acredito que se você tiver um indice decrescente no campo ID, a
> >> performance será praticamente a mesma. Faz um teste e retorne aqui.
> >>
> >> []s
> >> Carlos H. Cantu
> >> eBook Guia de Migração para o FB 3 - www.firebase.com.br/guiafb3.php
> >> www.FireBase.com.br - www.firebirdnews.org - blog.firebase.com.br
> >>
> >> CA> Olá! No meu Select, para se obter o maior ID, qual destas funções
> seria
> >> CA> mais apropriada e que utilizaria menos recurso de
> processador/memória?
> >>
> >> CA> select max(M2.ID)...
> >>
> >> CA> select M1.SALDO from CONTAS_MOV M1 where (M1.ID = (select max(M2.ID
> )
> >> CA> from CONTAS_MOV M2 where (M2.DATA <= current_date) and (M2.ID_EMP =
> 1)
> >> CA> and (M2.TIPO_MOV = 1)))
> >>
> >> CA> ou
> >>
> >> CA> select first 1 M2.ID...
> >>
> >> CA> select M1.SALDO from CONTAS_MOV M1 where (M1.ID = (select first 1
> >> M2.ID
> >> CA> from CONTAS_MOV M2 where (M2.DATA <= current_date) and (M2.ID_EMP =
> 1)
> >> CA> and (M2.TIPO_MOV = 1) order by M2.ID desc))
> >>
> >>
> >> CA> Eu tenho em mente que a função max é mais nativa, mas também que ela
> >> CA> pode contar vários registros até retornar o maior. Eu não sei o
> impacto
> >> CA> que isso causaria numa tabela com milhões de registros.
> >>
> >> CA> Já o first 1 pode retornar de imediato o primeiro registro, só que
> para
> >> CA> ele funcionar desta forma, eu tenho que utilizar: order by ID desc.
> >> CA> Acredito que assim eu não estarei utilizando o índice do campo por
> ser
> >> CA> uma PK Ascending.
>
>
> ______________________________________________
> 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
>



Mais detalhes sobre a lista de discussão lista