Re: *very* slow query to summarize data for a month ...

From: "Marc G(dot) Fournier" <scrappy(at)postgresql(dot)org>
To: Neil Conway <neilc(at)samurai(dot)com>
Cc: "Marc G(dot) Fournier" <scrappy(at)postgresql(dot)org>, pgsql-performance(at)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: *very* slow query to summarize data for a month ...
Date: 2003-11-11 00:19:56
Message-ID: 20031110201945.X727@ganymede.hub.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Mon, 10 Nov 2003, Neil Conway wrote:

> "Marc G. Fournier" <scrappy(at)postgresql(dot)org> writes:
> > -> Index Scan using tl_month on traffic_logs ts (cost=0.00..30763.02 rows=8213 width=16) (actual time=0.29..5562.25 rows=462198 loops=1)
> > Index Cond: (month_trunc(runtime) = '2003-10-01 00:00:00'::timestamp without time zone)
>
> Interesting that we get the row count estimate for this index scan so
> wrong -- I believe this is the root of the problem. Hmmm... I would
> guess that the optimizer stats we have for estimating the selectivity
> of a functional index is pretty primitive, but I haven't looked into
> it at all. Tom might be able to shed some light...
>
> [ In the second EXPLAIN ANALYZE, ... ]
>
> > -> Seq Scan on traffic_logs ts (cost=0.00..38340.72 rows=8213 width=16) (actual time=5.02..-645982.04 rows=462198 loops=1)
> > Filter: (date_trunc('month'::text, runtime) = '2003-10-01 00:00:00'::timestamp without time zone)
>
> Uh, what? The "actual time" seems to have finished far before it has
> begun :-) Is this just a typo, or does the actual output include a
> negative number?

This was purely a cut-n-paste ...

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Marc G. Fournier 2003-11-11 00:28:07 Re: *very* slow query to summarize data for a month ...
Previous Message Tom Lane 2003-11-10 23:42:09 Re: *very* slow query to summarize data for a month ...