Re: Optimization with dates

Yikes!  Good catch.  My example database returns on ~.6M for the last
30 days, and an index scan still turns out to be a win (of course, it
turned out to be a bigger win to have a separate table with 15 minute
summarizations of the data :).

Josh is right, chances are good that a sequential scan will actually
perform better for you than an index scan if you are returning 20% of
your entire table.

Jason

"Josh Berkus" <josh@agliodbs.com> writes:

> Jean-Christophe,
> 
> > Aggregate  (cost=256546.78..256546.78 rows=1 width=0)
> >   ->  Seq Scan on gains  (cost=0.00..250627.68 rows=2367640 width=0)
> > 
> > whereas :
> 
> Hmmm... if the number of rows is actually accurate (2M out of 10M in the
> last 30 days) then a Seq Scan seems like a good plan to me.  If the
> numbers aren't accurate, it's time to run a VACUUM ANALYZE.
> 
> Regardless, if you're actually querying for 2M recordsets, you'd better
> throw some hardware at the problem, and learn the .conf parameters.
> 
> -Josh
> 
> ______AGLIO DATABASE SOLUTIONS___________________________
>                                        Josh Berkus
>   Complete information technology      josh@agliodbs.com
>    and data management solutions       (415) 565-7293
>   for law firms, small businesses        fax 621-2533
>     and non-profit organizations.      San Francisco
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html