Em 2 de junho de 2017 10:46, Alexsander Rosa <alexsander.r...@gmail.com>
escreveu:
>
> A tabela tem cerca de 1 Gb:
> SELECT pg_size_pretty(pg_relation_size('cf_cupom'));
> pg_size_pretty
> ----------------
> 1114 MB
> (1 registro)
>
> Existe um índice UNIQUE no campo utilizado na query:
> "idx_cupom_chave" UNIQUE, btree (nfce_chave_acesso_fk) WHERE
nfce_chave_acesso_fk IS NOT NULL
>
> O campo utilizado também é FOREIGN KEY:
> "cupom_chave_nfe_fkey" FOREIGN KEY (nfce_chave_acesso_fk) REFERENCES
nfe_xml(chave_acesso) DEFERRABLE
>
> Código da procedure de teste:
> CREATE OR REPLACE FUNCTION rnx.sp_teste(chave text)
> RETURNS text
> LANGUAGE plpgsql
> AS $function$
> DECLARE
> BEGIN
> RAISE NOTICE '(%)', clock_timestamp()::timestamp(6);
> -- EXECUTE 'SELECT cod_empresa_fk FROM cf_cupom WHERE
nfce_chave_acesso_fk = $1' INTO empcupom USING chave;
> PERFORM num_cupom FROM cf_cupom WHERE nfce_chave_acesso_fk = chave;
> RAISE NOTICE '(%)', clock_timestamp()::timestamp(6);
> -- demora 1617 ms
>
> PERFORM chave_acesso from nfe_xml where chave_acesso = chave;
> RAISE NOTICE '(%)', clock_timestamp()::timestamp(6);
> -- demora 21 ms
>
> Return 'OK';
> END;
> $function$
> ;
>
> Comparativo:
> select sp_teste('43170605563868000113657010000004061895261728');
> -- demora 1630 ms
>
> select num_cupom FROM cf_cupom WHERE nfce_chave_acesso_fk =
'43170605563868000113657010000004061895261728';
> -- demora 11 ms
>
> Foi feito um VACUUM FULL ANALYZE na tabela.
> Alguém tem alguma dica para ajudar em nossa investigação?
>
Faz o seguinte, remove aqueles "RAISE NOTICE" da sua PL e roda no psql com
o "\timing on"...
Att,
--
Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
_______________________________________________
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
