Re: timestamp query doesn't use an index ...

On Sun, 21 May 2006, Michael Glaesemann wrote:

>
> On May 21, 2006, at 10:42 , Marc G. Fournier wrote:
>
>>   ->  Seq Scan on page_schedule ps2  (cost=0.00..2364.95 rows=33110 
>> width=16) (actual time=0.021..623.363 rows=94798 loops=1)
>
> I don't know about rewriting the query, but it appears your statistics are a 
> little out of date (e.g., rows expected/actual 33110/94798). Does running 
> ANALYZE help?

the data is idle, just loaded it on my desktop for testing purposes ... 
being paranoid, I have been doing a vacuum analyze on the table as I 
change the index's *just in case*, but, doing a full analyze on the whole 
database doesn't change the results any:

Actually, the above results are odd anyway, since a second run of the 
exact same query, shows more normal numbers:
                                                          QUERY PLAN 

-------------------------------------------------------------------------------------------------------------------------------
HashAggregate (cost=3051.91..3054.19 rows=183 width=16) (actual time=1030.970..1031.257 rows=128 loops=1)   ->  Seq
Scanon page_schedule ps2  (cost=0.00..2364.95 rows=91594 width=16) (actual time=0.019..636.599 rows=94798 loops=1)
  Filter: (timezone('MST7MDT'::text, start_time) <= '2006-05-17 08:09:18'::timestamp without time zone) Total runtime:
1031.681ms
 
(4 rows)

So not 100% certain where the 33110/94798 gap came from ;)

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email . scrappy@hub.org                              MSN . scrappy@hub.org
Yahoo . yscrappy               Skype: hub.org        ICQ . 7615664