[firebase-br] Plan no FB 1.0...

[Eduardo Jedliczka]

Eu perguntei e eu mesmo respondo...

Depois de mais de uma hora quebrando a cuca e fervendo os neurônios,
resolvemos testar várias coisas e se simplesmente trocar o Inner Join por um
Left Outer Join,  ele monta o seguinte plan, demorando 7 segundos( pior que
os 5 segundo informado o plan mas com 100% de tranquilidade):

PLAN SORT (JOIN (S INDEX (SAIDAS_DATAEMISSAO),C INDEX (RDB$PRIMARY88)))

[s] e mais uma vez obrigado,

==========================
Eduardo Jedliczka
Gerasoft Informática
Apucarana - Pr
==========================

----- Original Message ----- 
From: "Eduardo Jedliczka" <eduardo em gerasoft.com.br>
To: "FireBase-Br" <lista em firebase.com.br>
Sent: Friday, February 11, 2005 5:33 PM
Subject: [firebase-br] Plan no FB 1.0...


> Caros amigos,
>
> todos sabemos que o Otimizador (ou seria Pessimizador) do FireBird 1.0
> possui alguns "bugs"...
>
> Temos em nosso sistema a seguinte situação:
>
> Uma tabela de Saídas com 100 mil registros (de uma única empresa e
referente
> a um período de 6 meses) que pertencem aos quase 7 mil registros
cadastrados
> na tabela de Clientes.
>
> Já que nosso sistema é multi-empresa, existem as seguintes FKs:
> De clientes (CodEmpresa) com empresas (CodEmpresa);
> De saídas (CodCliente, CodEmpresa) com clientes (CodCliente, CodEmpresa);
> Há ainda um índice em saídas por DataEmissao, que é muito útil em vários
> partes do sistema...
>
> o problema é este select:
>
> Select C.UF, 'S' as Contribuinte,
> Sum(S.ValorContabil) as ValorContabil,
> from SAIDAS S
> Inner Join CLIENTES C on C.CodCliente=S.CodCliente and
> C.CodEmpresa=S.CodEmpresa
> Where s.CodEmpresa=:CodEmpresa and S.DataEmissao between :DataIni and
> :DataFim
> Group by C.UF
>
> Ao fazer um sum do valor das notas de saidas agrupadas pela UF dos
clientes
> de uma empresa específica em um determinado período, conforme o select
> acima, o FB 1.0 monta o seguinte PLAN:
>
> PLAN SORT (JOIN (C INDEX (RDB$FOREIGN122),S INDEX
> (RDB$FOREIGN131,SAIDAS_DATAEMISSAO)))
>
> e demora mais de um minuto para retornar os 5 registros agrupados...
>
> se "forçar-mos" o seguinte plan (sem a DATAEMISSAO), demora
aproximadamente
> 5 segundos...
> PLAN SORT (JOIN (C INDEX (RDB$FOREIGN122),S INDEX (RDB$FOREIGN131)))
>
> Como utilizamos FB 1.0 não dá para fazer group by por sub-select e nem
> renomear as FKs.
> E como temos mais de 150 clientes, não dá para migrá-los pro FB 1.5 muito
> facilmente.
> Além disto,achamos meio "suspeito" fazer um select nas tabelas de sistema
> para saber qual o nome "atual" do Índice das FKs após um backup/restore
para
> forçar o plan...
> Poderíamos utilizar uma SP para montar "separadamente" os Select, ou
montar
> o sum sobre uma VIEW, a performance seria boa, mas como é um relatório
para
> conferência, ou seja, utilizado com pouca freqüência, optamos em não
> realizar "alterações de estrutura" nas bases de nossos clientes
>
> Como sabemos que há várias pessoas na lista que já sofreram com problemas
> relacionados à performance, gostaria de saber algumas opniões dos membros
> desta lista sobre este assunto...
>
> A decisão mais acertada até agora é trazer os dados totalizados (sum) por
> código do cliente (6.850 registros) em uma consulta e os clientes (7.500
> registros) em outra e montar no terminal...
>
> [s]
>
> ==========================
> Eduardo Jedliczka
> Gerasoft Informática
> Apucarana - Pr
> ==========================
>
>
> ______________________________________________
> FireBase-BR (www.firebase.com.br) - Hospedado em www.bavs.com.br
> Para editar sua configuração na lista, use o endereço
http://mail.firebase.com.br/mailman/listinfo/lista_firebase.com.br
>
>