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

[Mário Reis]

Olá Cantú,

Haverá alguma forma de ir buscar a data/hora da ultima actualiza de um
registo às tabelas do sistema?
Quando usávamos db3++/clipper e o BDE engine havia um função LUPDATE() mas
com os RDMS/Sql não encontro nenhuma pista nesse sentido.

Se puder ajudar agradeço. Obrigado
Atentamente

Com os meus melhores cumprimentos
Mário Agostinho Reis

Esta mensagem contém informação de natureza confidencial e é
exclusivamente dirigida ao(s) destinatário(s) indicado(s). Se, por engano,
receber este email agradecemos que não o copie nem o reenvie e que nos
notifique do ocorrido através do email de resposta.

No dia 30 de junho de 2017 às 12:58, Carlos H. Cantu <listas em warmboot.com.br
> escreveu:

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