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 Scan on 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.681 ms
(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(at)hub(dot)org MSN . scrappy(at)hub(dot)org
Yahoo . yscrappy Skype: hub.org ICQ . 7615664