Matheus,
Segui as suas sugestões, criei o indice *(trip_program_id,
begintimestamp, COALESCE(endtimestamp, 'infinity')**)* que não surtiu muito
efeito e em seguida mudei a consulta conforme você sugeriu, neste eu tive
um resultado considerável, baixou para 28845.757 ms.
SELECT '' as linha,
On Mon, Apr 6, 2015 at 4:46 PM, Ariel Alves arielalves...@gmail.com wrote:
- Index Scan using
vehiclebusserviceplanned_tripprogramid_idx on vehiclebusserviceplanned vbp1
(cost=0.00..117.25 rows=9 width=16) (actual time=0.387..0.476 rows=0
loops=736406)
2015-04-06 16:58 GMT-03:00 Matheus de Oliveira matioli.math...@gmail.com:
On Mon, Apr 6, 2015 at 4:46 PM, Ariel Alves arielalves...@gmail.com
wrote:
- Index Scan using
vehiclebusserviceplanned_tripprogramid_idx on vehiclebusserviceplanned vbp1
(cost=0.00..117.25 rows=9
Em sex, 28 de nov de 2014 19:23, Marcos Thomaz marcosthom...@gmail.com
escreveu:
Ariel, na sua consulta existe mesmo essa sequencia de transformações
(cast) concatenando tipos? Porque por exemplo, no trecho:
(('2014-11-28'::date)::text || ' '::text) ||
(tp.departure_time)::text))::timestamp
On 28-11-2014 16:13, Ariel Alves wrote:
Boa tarde prezados,
Venho com mais um pedido de ajuda a vocês, estou homologando uma aplicação
e logo no inicio já me deparei com uma consulta muito lenta, peguei o
resultado explain analyze, vi que a lentidão estava concentrada
exclusivamente em um
Fabrízio,
As estatísticas estão atualizadas sim, apesar de ser uma base nova rodei um
analyze em todas conforme você sugeriu.
Obrigado.
Em 28 de novembro de 2014 16:19, Fabrízio de Royes Mello
fabri...@timbira.com.br escreveu:
On 28-11-2014 16:13, Ariel Alves wrote:
Boa tarde prezados,
On 28-11-2014 16:40, Ariel Alves wrote:
Fabrízio,
As estatísticas estão atualizadas sim, apesar de ser uma base nova rodei um
analyze em todas conforme você sugeriu.
Após o ANALYZE algo mudou?
Ps: evite top-posting.
--
Fabrízio de Royes Mello Timbira -
Ariel, na sua consulta existe mesmo essa sequencia de transformações (cast)
concatenando tipos? Porque por exemplo, no trecho:
(('2014-11-28'::date)::text || ' '::text) ||
(tp.departure_time)::text))::timestamp without time zone = begintimestamp)
o custo dessa série de concatenações é maior do
Rodrigo,
Após uma verificação *muito* superficial, segue meu pitaco ...
O problema não parece estar na query, mas no numero de queries
necessário para calcular devolvidos.
Vamos supor que em sua primeira tabela, vc tenha algo em torno de 100
registros...
Serão executadas 100 vezes a query da
..:: Rodrigo Machado ::.. wrote:
algum amigo poderia me dar uma mao?
segue o explain da consulta.. e mais a baixo a consulta propiamente.
Você tem certeza que o EXPLAIN informado corresponde a consulta
*grande*? Está me parecendo o EXPLAIN do SELECT dentro da função.
Não vi nada de anormal no
10 matches
Mail list logo
