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