Re: [pgbr-geral] SELECT simples lento dentro da procedure e rápido fora dela

2017-07-03 Por tôpico Alexsander Rosa 
Em 28 de junho de 2017 22:57, Ronaldo Bernardes Pereira <
ronaldobernar...@gmail.com> escreveu:

> --===   Como acredito que você irá resolver seu problema, seque
> considerações
>
> O problema encontrado é que o PostgreSQL fez um CAST da coluna (gn)
> (Filter: ((gn)::text = '900'::text)) para atender o tipo de argumento
> da FUNCTION que era do tipo text e no caso a coluna que ele comparava era
> do tipo char. Como o tamanho do campo tipo text pode ser muito maior do que
> um campo tipo char,  houve então o CAST implícito pelo PostgreSQL e com
> isso única alternativa que ele tinha nesse caso era fazer um seq scan, pois
> o índice não atendia para esse caso.
>
> --=== -->> Sugestões:
>
> 1 - Qual o tipo da coluna nfce_chave_acesso_fk e chave_acesso para
> entender melhor o problema?
>

Ambas são VARCHAR(44), esta é a chave de acesso de uma Nota Fiscal
Eletrônica (NFe e NFCe).


> 2 - Colocar o tipo do argumento da FUNCTION com o mesmo tipo da coluna,
> para não ocorrer CAST implícito das colunas nfce_chave_acesso_fk ou
> chave_acesso
>

Vamos fazer esta alteração, a procedure "sp_importa_xml_nfce" é nova e
ainda não está em produção.


> 3 - Caso não tenha como mudar (...)
> 4 - Executar e nos passar o resultado
>

Sim, testei aqui na "sp_teste" e funcionou. Muito obrigado! Em breve vamos
retomar o desenvolvimento do aplicativo Golang que consome a
"sp_importa_xml_nfce" e poderemos dar um retorno mais preciso.

-- 
Atenciosamente,
Alexsander da Rosa
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] SELECT simples lento dentro da procedure e rápido fora dela

2017-06-29 Por tôpico Fabrízio de Royes Mello 
Em 28 de junho de 2017 22:57, Ronaldo Bernardes Pereira <
ronaldobernar...@gmail.com> escreveu:
>
> ... [corte] ...
>
>
> --===   Como acredito que você irá resolver seu problema, seque
considerações
>
> O problema encontrado é que o PostgreSQL fez um CAST da coluna (gn)
(Filter: ((gn)::text = '900'::text)) para atender o tipo de argumento
da FUNCTION que era do tipo text e no caso a coluna que ele comparava era
do tipo char. Como o tamanho do campo tipo text pode ser muito maior do que
um campo tipo char,  houve então o CAST implícito pelo PostgreSQL e com
isso única alternativa que ele tinha nesse caso era fazer um seq scan, pois
o índice não atendia para esse caso.
>

Show de bola Ronaldo... excelente análise e retorno... é por esse tipo de
"cuidado" e "dedicação" sem compromisso que nunca deixo de acreditar em
comunidades.

Só por favor evite o top-posting.



> --=== -->> Sugestões:
>
> 1 - Qual o tipo da coluna nfce_chave_acesso_fk e chave_acesso para
entender melhor o problema?
>
> 2 - Colocar o tipo do argumento da FUNCTION com o mesmo tipo da coluna,
para não ocorrer CAST implícito das colunas nfce_chave_acesso_fk ou
chave_acesso
>
> 3 - Caso não tenha como mudar o tipo do argumento da FUNCTION, então
realizar o CAST explicito na variável (chave) no corpo FUNCTION na linha (
 PERFORM num_cupom FROM cf_cupom WHERE nfce_chave_acesso_fk = chave;)
>
> Ex: PERFORM num_cupom FROM cf_cupom WHERE nfce_chave_acesso_fk =
chave::bpchar;
>
> 4 - Executar e nos passar o resultado
>
>

Ótimo... e pior é que esse tipo de equívoco é mais comum do que parece e
nos passou totalmente desapercebido... porém lá no início da thread
deveriamos ter mais informações como a estrutura das tabelas envolvidas
então todos consideraram que os tipos de dados eram iguais e que outro
problema deveria estar ocorrendo... mas novamente nós como "seres humanos"
tendenciamos a complicar as coisas ao invés de simplificar.

Se puder depois @Alexsander dar um feedback, caso a sugestão do Ronaldo
ajudou para ai termos um bom histórico na nossa lista de discussão para
consultas futuras.

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

Re: [pgbr-geral] SELECT simples lento dentro da procedure e rápido fora dela

2017-06-28 Por tôpico Ronaldo Bernardes Pereira 
Alexsander, boa noite


Criei meu próprio exemplo para entender seu problema e chegar em uma
conclusão do que está ocorrendo.

--=== Criei uma tabela para teste a partir do generate_series

create table analyze_query as select
gn::character(20),'SomeTextExample'::text from generate_series(1,1000)
gn;


postgres=# \d analyze_query
 Tabela "public.analyze_query"
 Coluna | Tipo  | Modificadores
+---+---
 gn | character(10) |
 text   | text  |


--=== verificando o tamanho da tabela

postgres=# \dt+ analyze_query
 Lista de relações
 Esquema | Nome  |  Tipo  |   Dono   | Tamanho | Descrição
-+---++--+-+---
 public  | analyze_query | tabela | postgres | 574 MB  |


--=== Criei um index na coluna gn

create unique index on analyze_query(gn);


--=== Criei uma  FUNCTION parecida com a sua com o tipo do
argumento text

CREATE OR REPLACE FUNCTION sp_teste1(chave text)
 RETURNS text
 LANGUAGE plpgsql
AS $$
DECLARE
BEGIN
  PERFORM gn FROM analyze_query WHERE gn = chave;
  Return 'OK';
END;
$$;


--=== Executei o explain em um select parecido com o seu, para
comprovar que o índice seria usado

postgres=#  explain select gn FROM analyze_query WHERE gn ='900';
   QUERY PLAN

 Index Only Scan using analyze_query_gn_idx on analyze_query
(cost=0.43..8.45 rows=1 width=14)
   Index Cond: (gn = '900'::bpchar)
(2 registros)

--=== Query com tempo de execução

postgres=# select gn FROM analyze_query WHERE gn ='900';
 gn

 900
Tempo: 0,240 ms


--=== FUNCTION com tempo de execução, nesse caso o tempo foi muito
maior

postgres=# select sp_teste1('900');
 sp_teste1
---
 OK
(1 registro)

Tempo: 3144,483 ms

--===  Fiz o load do módulo auto explain para gerar plano de
execução automatico, tanto na tela como log do PostgreSQL.


LOAD 'auto_explain';
SET auto_explain.log_analyze TO on;
SET auto_explain.log_min_duration TO 0;
SET auto_explain.log_nested_statements TO on;
SET client_min_messages TO log;


--===  Executei a FUNCTION sp_teste1

Tempo: 16,121 ms
postgres=# select sp_teste1('900');
LOG:  duration: 3123.277 ms  plan:
Query Text: SELECT gn FROM analyze_query WHERE gn = chave
Seq Scan on analyze_query  (cost=0.00..223530.00 rows=5 width=14)
(actual time=2819.195..3123.258 rows=1 loops=1)
  Filter: ((gn)::text = '900'::text)
  Rows Removed by Filter: 999
CONTEXTO:  comando SQL "SELECT gn FROM analyze_query WHERE gn = chave"
função PL/pgSQL sp_teste1(text) linha 4 em PERFORM
LOG:  duration: 3123.736 ms  plan:
Query Text: select sp_teste1('900');
Result  (cost=0.00..0.26 rows=1 width=0) (actual time=3123.713..3123.716
rows=1 loops=1)
 sp_teste1
---
 OK
(1 registro)

Tempo: 3124,263 ms


--===   Plano  da query da FUNCTION sp_teste1, comprovando que
houve o seq scan

Seq Scan on analyze_query  (cost=0.00..223530.00 rows=5 width=14)
(actual time=2819.195..3123.258 rows=1 loops=1)
Filter: ((gn)::text = '900'::text)


--=== Alterei o argumento de (chave text) para (chave character(10))

CREATE OR REPLACE FUNCTION sp_teste2(chave character(10))
 RETURNS text
 LANGUAGE plpgsql
AS $$
DECLARE
BEGIN
  PERFORM gn FROM analyze_query WHERE gn = chave;
  Return 'OK';
END;
$$;


 --===  Fiz o teste também fazendo o CAST explicito e funcionou,
perfeitamente também como no exemplo anterior

 CREATE OR REPLACE FUNCTION sp_teste1(chave text)
 RETURNS text
 LANGUAGE plpgsql
AS $$
DECLARE
BEGIN
  PERFORM gn FROM analyze_query WHERE gn = chave::bpchar;  <<--- CAST
explicito
  Return 'OK';
END;
$$;

 --===   Executei novamente (Novo caso)


postgres=# select sp_teste2('900');
LOG:  duration: 0.292 ms  plan:
Query Text: SELECT gn FROM analyze_query WHERE gn = chave
Index Only Scan using analyze_query_gn_idx on analyze_query
(cost=0.43..8.45 rows=1 width=14) (actual time=0.264..0.267 rows=1 loops=1)
  Index Cond: (gn = '900'::bpchar)
  Heap Fetches: 1
CONTEXTO:  comando SQL "SELECT gn FROM analyze_query WHERE gn = chave"
função PL/pgSQL sp_teste3(character) linha 4 em PERFORM
LOG:  duration: 0.955 ms  plan:
Query Text: select sp_teste2('900');
Result  (cost=0.00..0.26 rows=1 width=0) (actual time=0.934..0.936 rows=1
loops=1)
 sp_teste3
---
 OK
(1 registro)


 --=== duration com a mudança tanto no argumento, como no CAST
explicito

LOG:  duration: 0.955 ms  plan:


Index Only Scan using analyze_query_gn_idx on analyze_query
(cost=0.43..8.45 rows=1 width=14) (actual time=0.264..0.267 rows=1 loops=1)
  Index Cond: (gn = '900'::bpchar)


 --=== Executar novamente (Caso antigo)


postgres=# select sp_teste1('900');
LOG:  duration: 3141.335 ms  plan:
Query

Re: [pgbr-geral] SELECT simples lento dentro da procedure e rápido fora dela

2017-06-02 Por tôpico Alexsander Rosa 
Em 2 de junho de 2017 16:40, Matheus de Oliveira 
escreveu:

> Isso aí pra mim tá com cara de plano de execução genérico. Mas pra ter
> certeza seria legal você instalar e habilitar o auto_explain, daí você
> configura `auto_explain.log_nested_statements = on`  e executa a função
> novamente, ele vai logar o plano de execução só daquela consulta no log.
>
> postgres=# SELECT sp_teste('43170605563868000113657010
> 04061895261728');
> ...  ...
>
>
O banco um Seq Scan... ignorou o índice.

central-rd540:5432:rnge2=# SELECT
sp_teste('4317060556386800011365701004061895261728');
LOG:  duration: 1810.362 ms  plan:
Query Text: SELECT num_cupom FROM cf_cupom WHERE nfce_chave_acesso_fk =
chave
Seq Scan on cf_cupom  (cost=0.00..305178.52 rows=54145 width=4) (actual
time=1806.082..1810.358 rows=1 loops=1)
  Filter: ((nfce_chave_acesso_fk)::text =
'4317060556386800011365701004061895261728'::text)
  Rows Removed by Filter: 10793976
LOG:  duration: 1834.088 ms  plan:
Query Text: SELECT sp_teste('4317060556386800011365701004061895261728');
Result  (cost=0.00..0.26 rows=1 width=0) (actual time=1834.080..1834.080
rows=1 loops=1)
 sp_teste
--
 OK


-- 
Atenciosamente,
Alexsander da Rosa
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] SELECT simples lento dentro da procedure e rápido fora dela

2017-06-02 Por tôpico Matheus de Oliveira 
On Fri, Jun 2, 2017 at 3:00 PM, Alexsander Rosa 
wrote:

> laboratorio:rnge2=# *EXPLAIN (ANALYZE, TIMING, BUFFERS) SELECT
> sp_teste('4317060556386800011365701004061895261728');*
> QUERY PLAN
>
> 
> --
>  Result  (cost=0.00..0.04 rows=1 width=0) (actual time=1494.473..1494.473
> rows=1 loops=1)
>Buffers: shared hit=18939 read=123331
>  Total runtime: 1494.496 ms
> (3 rows)
>

Isso aí pra mim tá com cara de plano de execução genérico. Mas pra ter
certeza seria legal você instalar e habilitar o auto_explain, daí você
configura `auto_explain.log_nested_statements = on`  e executa a função
novamente, ele vai logar o plano de execução só daquela consulta no log.

Se quiser dá pra fazer na sua sessão direto:

postgres=# LOAD 'auto_explain';
LOAD
postgres=# SET auto_explain.log_analyze TO on;
SET
postgres=# SET auto_explain.log_min_duration TO 0;
SET
postgres=# SET auto_explain.log_nested_statements TO on;
SET
postgres=# SET client_min_messages TO log;
SET
postgres=# SELECT
sp_teste('4317060556386800011365701004061895261728');
...  ...


Atenciosamente,

-- 
Matheus de Oliveira
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] SELECT simples lento dentro da procedure e rápido fora dela

2017-06-02 Por tôpico Alexsander Rosa 
Em 2 de junho de 2017 14:34, Fabrízio de Royes Mello <
fabri...@timbira.com.br> escreveu:

>
> Em 2 de junho de 2017 12:32, Alexsander Rosa 
> escreveu:
> > (...)
> > Coloquei STABLE e não mudou nada:
> >
>
> Roda o ajuste abaixo (além do STABLE) e roda novamente o teste:
>
> ALTER FUNCTION sp_teste(text) COST 10;
>
>
laboratorio:rnge2=# *ALTER FUNCTION sp_teste(text) COST 10;*
ALTER FUNCTION
laboratorio:rnge2=# *EXPLAIN (ANALYZE, TIMING, BUFFERS) SELECT
sp_teste('4317060556386800011365701004061895261728');*
QUERY PLAN

--
 Result  (cost=0.00..0.04 rows=1 width=0) (actual time=1494.473..1494.473
rows=1 loops=1)
   Buffers: shared hit=18939 read=123331
 Total runtime: 1494.496 ms
(3 rows)

laboratorio:rnge2=# *SELECT pg_get_functiondef('sp_teste'::regproc);*
  pg_get_functiondef
---
 CREATE OR REPLACE FUNCTION rnx.sp_teste(chave text)  +
  RETURNS text+
  LANGUAGE plpgsql+
  STABLE COST 10  +
 AS $function$+
 DECLARE  +
 BEGIN+
   PERFORM num_cupom FROM cf_cupom WHERE nfce_chave_acesso_fk = chave;+
   Return 'OK';   +
 END; +
 $function$   +

(1 row)

Atenciosamente,
Alexsander da Rosa
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] SELECT simples lento dentro da procedure e rápido fora dela

2017-06-02 Por tôpico Fabrízio de Royes Mello 
Em 2 de junho de 2017 12:32, Alexsander Rosa 
escreveu:
>
> 2017-06-02 11:50 GMT-03:00 Flavio Henrique Araque Gurgel :
>>
>> Para de bagunça a lista, pelamor.
>> A gente responde LÁ EMBAIXO ! olha só:
>
>
> Coloquei STABLE e não mudou nada:
> EXPLAIN (ANALYZE, TIMING, BUFFERS) SELECT
sp_teste('4317060556386800011365701004061895261728');
> QUERY PLAN

>
--
>  Result  (cost=0.00..0.26 rows=1 width=0) (actual time=1478.944..1478.944
rows=1 loops=1)
>Buffers: shared hit=18731 read=123491
>  Total runtime: 1478.955 ms
> (3 rows)
>

Roda o ajuste abaixo (além do STABLE) e roda novamente o teste:

ALTER FUNCTION sp_teste(text) COST 10;

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

Re: [pgbr-geral] SELECT simples lento dentro da procedure e rápido fora dela

2017-06-02 Por tôpico Alexsander Rosa 
2017-06-02 11:50 GMT-03:00 Flavio Henrique Araque Gurgel :

> Para de bagunça a lista, pelamor.
> A gente responde LÁ EMBAIXO ! olha só:
>

Coloquei STABLE e não mudou nada:
EXPLAIN (ANALYZE, TIMING, BUFFERS) SELECT
sp_teste('4317060556386800011365701004061895261728');
QUERY PLAN

--
 Result  (cost=0.00..0.26 rows=1 width=0) (actual time=1478.944..1478.944
rows=1 loops=1)
   Buffers: shared hit=18731 read=123491
 Total runtime: 1478.955 ms
(3 rows)

-- 
Atenciosamente,
Alexsander da Rosa
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] SELECT simples lento dentro da procedure e rápido fora dela

2017-06-02 Por tôpico Flavio Henrique Araque Gurgel 
Para de bagunça a lista, pelamor.
A gente responde LÁ EMBAIXO ! olha só:

Em sex, 2 de jun de 2017 às 16:39, Alexsander Rosa <
alexsander.r...@gmail.com> escreveu:

> laboratorio:rnge2=# EXPLAIN (ANALYZE, TIMING, BUFFERS) SELECT num_cupom
> FROM cf_cupom WHERE nfce_chave_acesso_fk =
> '4317060556386800011365701004061895261728';
> QUERY PLAN
>
>
> --
>  Index Scan using idx_cupom_chave on cf_cupom  (cost=0.55..8.57 rows=1
> width=4) (actual time=0.078..0.079 rows=1 loops=1)
>Index Cond: (nfce_chave_acesso_fk =
> '4317060556386800011365701004061895261728'::bpchar)
>Buffers: shared hit=5
>  Total runtime: 0.106 ms
> (4 rows)
>
>
> 2017-06-02 11:28 GMT-03:00 Alexsander Rosa :
>
>> laboratorio:rnge2=# EXPLAIN (ANALYZE, TIMING, BUFFERS) SELECT
>> sp_teste('4317060556386800011365701004061895261728');
>> QUERY PLAN
>>
>>
>> --
>>  Result  (cost=0.00..0.26 rows=1 width=0) (actual time=1523.013..1523.013
>> rows=1 loops=1)
>>Buffers: shared hit=18998 read=123619 dirtied=3
>>  Total runtime: 1523.043 ms
>> (3 rows)
>>
>>
>> Em 2 de junho de 2017 11:11, Alexsander Rosa 
>> escreveu:
>>
>>> laboratorio:rnge2=# SELECT
>>> sp_teste('4317060556386800011365701004061895261728');
>>>  sp_teste
>>> --
>>>  OK
>>> (1 row)
>>>
>>> Time: 1507,688 ms
>>> laboratorio:rnge2=#
>>>
>>> 
>>> -- Código "pelado"
>>> CREATE OR REPLACE FUNCTION rnx.sp_teste(chave text)
>>>  RETURNS text
>>>  LANGUAGE plpgsql
>>> AS $function$
>>> DECLARE
>>> BEGIN
>>>   PERFORM num_cupom FROM cf_cupom WHERE nfce_chave_acesso_fk = chave;
>>>   Return 'OK';
>>> END;
>>> $function$
>>> ;
>>>
>>
Declare sua função como STABLE e tenta novamente.

[]s
Flavio Gurgel
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] SELECT simples lento dentro da procedure e rápido fora dela

2017-06-02 Por tôpico Alexsander Rosa 
laboratorio:rnge2=# EXPLAIN (ANALYZE, TIMING, BUFFERS) SELECT num_cupom
FROM cf_cupom WHERE nfce_chave_acesso_fk =
'4317060556386800011365701004061895261728';
QUERY PLAN

--
 Index Scan using idx_cupom_chave on cf_cupom  (cost=0.55..8.57 rows=1
width=4) (actual time=0.078..0.079 rows=1 loops=1)
   Index Cond: (nfce_chave_acesso_fk =
'4317060556386800011365701004061895261728'::bpchar)
   Buffers: shared hit=5
 Total runtime: 0.106 ms
(4 rows)


2017-06-02 11:28 GMT-03:00 Alexsander Rosa :

> laboratorio:rnge2=# EXPLAIN (ANALYZE, TIMING, BUFFERS) SELECT sp_teste('
> 4317060556386800011365701004061895261728');
> QUERY PLAN
>
> 
> --
>  Result  (cost=0.00..0.26 rows=1 width=0) (actual time=1523.013..1523.013
> rows=1 loops=1)
>Buffers: shared hit=18998 read=123619 dirtied=3
>  Total runtime: 1523.043 ms
> (3 rows)
>
>
> Em 2 de junho de 2017 11:11, Alexsander Rosa 
> escreveu:
>
>> laboratorio:rnge2=# SELECT sp_teste('43170605563868000113
>> 65701004061895261728');
>>  sp_teste
>> --
>>  OK
>> (1 row)
>>
>> Time: 1507,688 ms
>> laboratorio:rnge2=#
>>
>> 
>> -- Código "pelado"
>> CREATE OR REPLACE FUNCTION rnx.sp_teste(chave text)
>>  RETURNS text
>>  LANGUAGE plpgsql
>> AS $function$
>> DECLARE
>> BEGIN
>>   PERFORM num_cupom FROM cf_cupom WHERE nfce_chave_acesso_fk = chave;
>>   Return 'OK';
>> END;
>> $function$
>> ;
>>
>> 
>> -- EXPLAIN:
>>
>> Index Scan using idx_cupom_chave on cf_cupom  (cost=0.55..8.57 rows=1
>> width=4)
>>   Index Cond: (nfce_chave_acesso_fk = '4317060556386800011365701
>> 004061895261728'::bpchar)
>>
>>
>> Em 2 de junho de 2017 11:06, Flavio Henrique Araque Gurgel <
>> fha...@gmail.com> escreveu:
>>
>>> Em sex, 2 de jun de 2017 às 15:55, Fabrízio de Royes Mello <
>>> fabri...@timbira.com.br> escreveu:
>>>


 Em 2 de junho de 2017 10:46, Alexsander Rosa 
 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('4317060556386800011365701004061895261728');
 > -- demora 1630 ms
 >
 > select num_cupom FROM cf_cupom WHERE nfce_chave_acesso_fk =
 '4317060556386800011365701004061895261728';
 > -- 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"...

>>>
>>> Ah, vou eleger 2 de junho como dia internacional da consulta lenta
>>> inexplicável... só hoje foram duas no meu trampo.
>>>
>>> Ao OP, cadê os EXPLAIN (analyze, timing, buffers) SELECT... ?
>>>
>>> []s
>>> Flavio Gurgel
>>>
>>>
>>> ___
>>> pgbr-geral mailing list
>>> pgbr-geral@listas.postgresql.org.br
>>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>>>
>>
>>
>>
>> --
>> Atenciosamente,
>> Alexsander da Rosa
>>
>>
>
>
> --
> Atenciosamente,
> Alexsander da Rosa
>
>


-- 
Atenciosamente,
Alexsander da Rosa
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] SELECT simples lento dentro da procedure e rápido fora dela

2017-06-02 Por tôpico Alexsander Rosa 
laboratorio:rnge2=# EXPLAIN (ANALYZE, TIMING, BUFFERS) SELECT
sp_teste('4317060556386800011365701004061895261728');
QUERY PLAN

--
 Result  (cost=0.00..0.26 rows=1 width=0) (actual time=1523.013..1523.013
rows=1 loops=1)
   Buffers: shared hit=18998 read=123619 dirtied=3
 Total runtime: 1523.043 ms
(3 rows)


Em 2 de junho de 2017 11:11, Alexsander Rosa 
escreveu:

> laboratorio:rnge2=# SELECT sp_teste('43170605563868000113
> 65701004061895261728');
>  sp_teste
> --
>  OK
> (1 row)
>
> Time: 1507,688 ms
> laboratorio:rnge2=#
>
> 
> -- Código "pelado"
> CREATE OR REPLACE FUNCTION rnx.sp_teste(chave text)
>  RETURNS text
>  LANGUAGE plpgsql
> AS $function$
> DECLARE
> BEGIN
>   PERFORM num_cupom FROM cf_cupom WHERE nfce_chave_acesso_fk = chave;
>   Return 'OK';
> END;
> $function$
> ;
>
> 
> -- EXPLAIN:
>
> Index Scan using idx_cupom_chave on cf_cupom  (cost=0.55..8.57 rows=1
> width=4)
>   Index Cond: (nfce_chave_acesso_fk = '43170605563868000113657010
> 04061895261728'::bpchar)
>
>
> Em 2 de junho de 2017 11:06, Flavio Henrique Araque Gurgel <
> fha...@gmail.com> escreveu:
>
>> Em sex, 2 de jun de 2017 às 15:55, Fabrízio de Royes Mello <
>> fabri...@timbira.com.br> escreveu:
>>
>>>
>>>
>>> Em 2 de junho de 2017 10:46, Alexsander Rosa 
>>> 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('4317060556386800011365701004061895261728');
>>> > -- demora 1630 ms
>>> >
>>> > select num_cupom FROM cf_cupom WHERE nfce_chave_acesso_fk =
>>> '4317060556386800011365701004061895261728';
>>> > -- 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"...
>>>
>>
>> Ah, vou eleger 2 de junho como dia internacional da consulta lenta
>> inexplicável... só hoje foram duas no meu trampo.
>>
>> Ao OP, cadê os EXPLAIN (analyze, timing, buffers) SELECT... ?
>>
>> []s
>> Flavio Gurgel
>>
>>
>> ___
>> pgbr-geral mailing list
>> pgbr-geral@listas.postgresql.org.br
>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>>
>
>
>
> --
> Atenciosamente,
> Alexsander da Rosa
>
>


-- 
Atenciosamente,
Alexsander da Rosa
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] SELECT simples lento dentro da procedure e rápido fora dela

2017-06-02 Por tôpico Alexsander Rosa 
laboratorio:rnge2=# SELECT sp_teste('43170605563868000113
65701004061895261728');
 sp_teste
--
 OK
(1 row)

Time: 1507,688 ms
laboratorio:rnge2=#


-- Código "pelado"
CREATE OR REPLACE FUNCTION rnx.sp_teste(chave text)
 RETURNS text
 LANGUAGE plpgsql
AS $function$
DECLARE
BEGIN
  PERFORM num_cupom FROM cf_cupom WHERE nfce_chave_acesso_fk = chave;
  Return 'OK';
END;
$function$
;


-- EXPLAIN:

Index Scan using idx_cupom_chave on cf_cupom  (cost=0.55..8.57 rows=1
width=4)
  Index Cond: (nfce_chave_acesso_fk =
'4317060556386800011365701004061895261728'::bpchar)


Em 2 de junho de 2017 11:06, Flavio Henrique Araque Gurgel  escreveu:

> Em sex, 2 de jun de 2017 às 15:55, Fabrízio de Royes Mello <
> fabri...@timbira.com.br> escreveu:
>
>>
>>
>> Em 2 de junho de 2017 10:46, Alexsander Rosa 
>> 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('4317060556386800011365701004061895261728');
>> > -- demora 1630 ms
>> >
>> > select num_cupom FROM cf_cupom WHERE nfce_chave_acesso_fk = '
>> 4317060556386800011365701004061895261728';
>> > -- 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"...
>>
>
> Ah, vou eleger 2 de junho como dia internacional da consulta lenta
> inexplicável... só hoje foram duas no meu trampo.
>
> Ao OP, cadê os EXPLAIN (analyze, timing, buffers) SELECT... ?
>
> []s
> Flavio Gurgel
>
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>



-- 
Atenciosamente,
Alexsander da Rosa
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] SELECT simples lento dentro da procedure e rápido fora dela

2017-06-02 Por tôpico Flavio Henrique Araque Gurgel 
Em sex, 2 de jun de 2017 às 15:55, Fabrízio de Royes Mello <
fabri...@timbira.com.br> escreveu:

>
>
> Em 2 de junho de 2017 10:46, Alexsander Rosa 
> 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('4317060556386800011365701004061895261728');
> > -- demora 1630 ms
> >
> > select num_cupom FROM cf_cupom WHERE nfce_chave_acesso_fk =
> '4317060556386800011365701004061895261728';
> > -- 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"...
>

Ah, vou eleger 2 de junho como dia internacional da consulta lenta
inexplicável... só hoje foram duas no meu trampo.

Ao OP, cadê os EXPLAIN (analyze, timing, buffers) SELECT... ?

[]s
Flavio Gurgel
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] SELECT simples lento dentro da procedure e rápido fora dela

2017-06-02 Por tôpico Fabrízio de Royes Mello 
Em 2 de junho de 2017 10:46, Alexsander Rosa 
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('4317060556386800011365701004061895261728');
> -- demora 1630 ms
>
> select num_cupom FROM cf_cupom WHERE nfce_chave_acesso_fk =
'4317060556386800011365701004061895261728';
> -- 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

[pgbr-geral] SELECT simples lento dentro da procedure e rápido fora dela

2017-06-02 Por tôpico Alexsander Rosa 
*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('4317060556386800011365701004061895261728');
-- demora 1630 ms

select num_cupom FROM cf_cupom WHERE nfce_chave_acesso_fk =
'4317060556386800011365701004061895261728';
-- demora 11 ms

Foi feito um VACUUM FULL ANALYZE na tabela.
Alguém tem alguma dica para ajudar em nossa investigação?

-- 
Atenciosamente,
Alexsander da Rosa
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral