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(at)agliodbs(dot)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(at)agliodbs(dot)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(at)postgresql(dot)org