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

[Eduardo Jedliczka]

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
==========================