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 =
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:
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
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
On Fri, Jun 2, 2017 at 3:00 PM, Alexsander Rosa
wrote:
> laboratorio:rnge2=# *EXPLAIN (ANALYZE, TIMING, BUFFERS) SELECT
> sp_teste('4317060556386800011365701004061895261728');*
> QUERY PLAN
>
>
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
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:
>
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');
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 =
>
laboratorio:rnge2=# EXPLAIN (ANALYZE, TIMING, BUFFERS) SELECT num_cupom
FROM cf_cupom WHERE nfce_chave_acesso_fk =
'4317060556386800011365701004061895261728';
QUERY PLAN
laboratorio:rnge2=# EXPLAIN (ANALYZE, TIMING, BUFFERS) SELECT
sp_teste('4317060556386800011365701004061895261728');
QUERY PLAN
--
Result (cost=0.00..0.26 rows=1
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$
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'));
> >
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:
>
14 matches
Mail list logo