[firebase-br] RES: RES: RES: RES: Melhorar velocidade na consulta

[Douglas Tosi]

2009/7/7 Marcelo Moreira <marcelomoreira.souza em gmail.com>:
> Quantos registros tem a tabela?
>
> R: Esta tabela nao fica com muitos registros armazenados pois a medida que o
> sistema vai trabalhando ele retira o registro desta tabela e joga em outra
> tabela identica onde vou guardando o historico. Só pra voce entender se
> trata de um sistema que realiza envio de SMS em massa. Entao vamos imaginar
> que um cliente me enviou uma remessa de 100.000 registros. A medida que as
> mensagens vao sendo enviadas a tabela vai ficando com menos registros. Ou
> seja nesta tabela hora pode ter 100.000 hora pode ter 100 registro ou ate
> mesmo nada.

Um outro problema que você pode ter é depois de apagar uma massa de
dados, o próximo select vai tentar fazer garbage collect. Isto pode
demorar. Será que não é isto? Ou o comando é lento todas as vezes?

> Qual a distribuição de valores nos campos id_envia_status e prioridade?
> R: ID_ENVIA_STATUS só assume dois valores (1 - Pendente; 2 - Reservado) e
> prioridade tambem so pode assumir dois  valores (1; 2)

Estes casos são complicados porque dependem do tempo.
Novamente, qual o plano de execução?

De qualquer maneira vale uma tentativa:
Crie um índice em hora_final e teste com o seu sql original e também com esse:
update
     ENVIA E
   set
     E.ID_ENVIA_STATUS = 2
   where
     E.ID_ENVIA = (  select
   first(1) EN.ID_ENVIA
 from
   ENVIA EN
 where
   (EN.ID_ENVIA_STATUS = 1) and
   (EN.PRIORIDADE = 1) and
   (current_date >= EN.DATA_INICIAL) and
   (current_time between EN.HORA_INICIAL and EN.HORA_FINAL)
order by en.hora_final)

-- 
Douglas Tosi
www.sinatica.com