Em 2 de junho de 2017 10:46, Alexsander Rosa <[email protected]> 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 [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
