>________________________________ > De: Marcone <marconepe...@gmail.com> >Para: Jean Domingues <ejdom...@yahoo.com.br>; Comunidade PostgreSQL Brasileira ><pgbr-geral@listas.postgresql.org.br> >Enviadas: Quarta-feira, 12 de Setembro de 2012 14:52 >Assunto: Re: [pgbr-geral] Interpretar explain > >Em 12 de setembro de 2012 14:10, Jean Domingues ><ejdom...@yahoo.com.br> escreveu: >> Tá certo. Não passei por achar que era muita informação. Vamos lá: >> >> 1) a Tabela compras (a exemplo) >> >> CREATE TABLE public.compras ( >> id BIGINT NOT NULL, >> id_empresa INTEGER NOT NULL, >> id_terceiro INTEGER NOT NULL, >> num_ped_compra_interno INTEGER NOT NULL, >... ><corte> >... >> CREATE INDEX compras_idx1 ON public.compras >> >> USING btree (id_empresa, data_ped_compra); >> >> CREATE INDEX compras_idx10 ON public.compras >> USING btree (ct_id_compra_vinculada); >... ><corte> >... > >> 2) a View >> CREATE VIEW public.view_fila_nfe ( >> id, >> ... >> tipo_emissao) >> >> AS >> SELECT nfe.id, nfe.id_fila, f.desc_fila, nfe.id_compra, nfe.id_venda, >> sp_formata_danfe(nfe.danfe) AS danfe, nfe.recibo, nfe.protocolo, >>nfe.xml_nao_assinado, nfe.xml_assinado, nfe.dh_fila, nfe.dh_envio, >>nfe.dh_retorno, nfe.dh_cancelamento, nfe.dh_impressao, nfe.numero_chave, >>nfe.dv_chave, nfe.status_envio, nfe.status_retorno, nfe.email, >>nfe.dh_envio_email, nfe.nao_enviar_email, nfe.erro_email, nfe.numero_nf, >>nfe.id_empresa, nfe.serie_nf, >> CASE nfe.id_compra IS NOT NULL >> WHEN true THEN c.num_ped_compra_interno >> ELSE v.numero_doc >> END AS numero_doc, nfe.id_terceiro, t1.razao_social, t1.nome AS >... ><corte> >... >> >> explain >> select * from view_fila_nfe where (id_empresa = 1) and >> (id_fila = 1) and (status_retorno = '1') and >> (coalesce(email, '') <> '') AND (((dh_cancelamento IS NULL) AND >> (dh_envio_email IS NULL) >> AND (nao_enviar_email = false)) or ((dh_cancelamento IS NOT NULL) >> AND (dh_envio_email_canc IS NULL) AND (nao_enviar_email_canc = false))) >> order by numero_nf, id > >Cara isso que você passou é muita coisa mas ainda diz pouco sobre seu modelo. > >Bom vou tentar te ajudar: > >1) Com o Dutra falou, sua tabela tem muita coisa, cabe uma normalização. E qual seria a normalização?
>2) Ter índice não significa que o planejador irá usá-lo. >3) Vou dar um chute apenas: na linha 24 do explain que vocẽ enviou >informa o custo de busca do seq_scan em compras (cost=0.00..5125.69 >rows=79569), a única referência para compras é n left join na view. >Minha opnião é que por esses dois motivos (custo baixo e left join) o >planejador ignora o índice. Não sei a lógica do negócio, mas creio que >se você trocar o left join por inner join com a tabela compras, creio >que o planejador utilizará o índice. E certamente utilizará se >compras.id fizer parte de uma filtro. Não posso pois existem registros na nfe que apontam pra vendas, e outros que apontam pra compras. Veja que, no caso de vendas, ele usou o índice da chave. >4) Uma pergunta: Sua consulta está lenta? (estou partindo do princípio >que sim) Quanto tempo está demorando? O fato de não usar esse índice >especificamente não quer dizer que seja o motivo dessa lentidão. Está lenta... com os dados em cache, leva em torno de 6s. Sem cache, 30s. > >-- >Marcone Peres - DBA >http://www.linkedin.com/in/marconeperes >@marconeperes >(61) 8146-0028 > > > _______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
