[firebase-br] Firebird 3.02 e o Problema com os PLAN

[Alexandre Benson Smith]

Anderson,

Como fica se você executar a seguinte query:

SELECT
	V.COD_VENDA,
	V.CODCLI_VENDA as CodCli,
	CL.NOME_CLIENTE
FROM
	VENDAS V JOIN
	CLIENTES CL ON (V.CODCLI_VENDA+0 = CL.COD_CLIENTE)
where
	v.DATA_VENDA >= '21.06.2017'


Estranho o otimizador escolher este plano....  A primeira coisa que eu 
iria olhar eram as estatísticas, mas você já disse que estão 
atualizadas, segunda coisa olhar se algum índice esta inativo por algum 
motivo mas são PK/FK então não deveriam estar inativos, terceira seria 
olhar os tipos de dados dos campos se estão corretos e compatíveis (ex. 
se não é o caso de ter um campo integer e outro varchar), mas pelo DDL 
que postou, está tb certo...

[]s

Em 30/6/2017 09:17, Anderson Barretta escreveu:
> olá pessoal,
> fazem uns 3 meses que migrei vários clientes para o Fb3.
>   a principio tudo ok,
> mas estamos enfrentando algumas lentidoes em querys que antes no Fb 2.5
> tinham um bom desempenho.
>
> pelo que li aqui no fórum e no BUG tracker do Firebird mais pessoas estão
> com esse problema.
>
> vou mostrar um exemplo bem simples, apenas com 2 tabelas
> onde no meu ver o Firebird escolhe de forma errada o PLAN
>
> tenho 2 tabelas bem simples:
>
> CREATE TABLE CLIENTES (
>      COD_CLIENTE   DM_ID /* DM_ID = INTEGER NOT NULL */,
>      NOME_CLIENTE  DM_NOME /* DM_NOME = VARCHAR(60) */
> );
> ALTER TABLE CLIENTES ADD CONSTRAINT PK_CLIENTES
> PRIMARY KEY (COD_CLIENTE);
>
> --------------------------
>
> CREATE TABLE VENDAS (
>      COD_VENDA     DM_ID /* DM_ID = INTEGER NOT NULL */,
>      DATA_VENDA    DM_DATA /* DM_DATA = DATE */,
>      CODCLI_VENDA  DM_ID /* DM_ID = INTEGER NOT NULL */
> );
>
> ALTER TABLE VENDAS ADD CONSTRAINT PK_VENDAS PRIMARY KEY (COD_VENDA);
> CREATE INDEX VENDAS_IDX_CLI ON VENDAS (CODCLI_VENDA);
> CREATE INDEX VENDAS_IDX_DATA ON VENDAS (DATA_VENDA);
>
>
> a tabela de clientes tem 2.383 registros
> a tabela de vendas tem 2.299.899 registros
>
> e fazendo um select simples :
>
> SELECT
> V.COD_VENDA,
> V.CODCLI_VENDA as CodCli,
> CL.NOME_CLIENTE
> FROM
> VENDAS V JOIN CLIENTES CL ON (V.CODCLI_VENDA = CL.COD_CLIENTE)
> where v.DATA_VENDA >= '21.06.2017'
>
> o FB acaba optando  pela busca natural da tabela de clinetes
> onde o mais correto no meu ver, seria utilizar a PK da tabela:
>
> PLAN JOIN (CL NATURAL, V INDEX (VENDAS_IDX_CLI, VENDAS_IDX_DATA))
>
> isso acaba dando uma diferença significativa quando a tabela de clientes
> tem bastante registros.
>
> fiz vários testes aqui, fiz backup e restaurei...
>
> a seletividade do indice VENDAS_IDX_CLI é de
> 0.0004196391091682017
>
> acredito que isso seja um BUG do otimizador do Fb 3.
> pois no Fb2.5 pega o PLAN correto.
>
> tenho o backup da base (8MB) se alguem quiser testar...
>
>
>
>


-- 
Alexandre Benson Smith
Santo Andre - Sao Paulo - Brazil