I have a similar table (~16M rows) with an indexed timestamp, and have
had similar problems. I have found that even when I am using a
constant timestamp like in this query.
SELECT * FROM caseweights1 WHERE dt > '2001-11-01';
I start getting sequential scans with 7.1.3 long before they are
faster than index based queries. I believe that there is a constant
that can be fiddled to modify this behavior, and it seems like I have
also read that this constant has been modified in the new 7.2 release.
However, for queries that you *know* will be faster using the index
you can always issue:
set enable_seqscan to off;
before running your query. This will force PostgreSQL to use the
index even in queries like this one:
SELECT * FROM caseweights1 WHERE dt > (SELECT now() - '30 days'::interval);
Jason
Jean-Christophe Boggio <cat@thefreecat.org> writes:
> Hello,
>
> I really have a problem dealing with dates :
>
> I have a big table (~10M rows) like :
>
> create table gains (
> dategain timestamp,
> otherfields
> );
>
> There's an index on dategain and I want to use it to get the last
> 30 days records :
>
> explain select count(*) from gains where dategain>=now()-30;
>
> Aggregate (cost=256546.78..256546.78 rows=1 width=0)
> -> Seq Scan on gains (cost=0.00..250627.68 rows=2367640 width=0)
>
> whereas :
>
> explain select count(*) from gains where dategain>='now';
>
> Aggregate (cost=27338.47..27338.47 rows=1 width=0)
> -> Index Scan using ix_gains_dategain on gains (cost=0.00..27320.71 rows=7103 width=0)
>
> I have tried :
> where dategain>=(select now()-30);
> where dategain+30>='now'
> where date(dategain)>=date('now')-30
> and many other, syntactically absurd :-)
>
> Anyone can help me use this index ?
>
> TIA,
>
> --
> Jean-Christophe Boggio
> cat@thefreecat.org -o)
> Independant Consultant and Developer /\\
> Delphi, Linux, Perl, PostgreSQL, Debian _\_V
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster