> >
> > OK, I'm now more confused. What do I do next to figure out why
> > postgres isn't choosing the better query? We're running a vacuum
> > analyze every
> > night-- do I need to tweak the weights so that seq_scan is
> less likely?
>
> Hmm, I'm not sure what the best answer is for this, it's
> getting beyond my depth. I'd guess that it's possible that
> it's over estimating the number of reads necessary to do the
> index scan because the rows are clustered together which
> would make it over-estimate the index scan cost and/or it
> could be underestimating the cost of the sequence scan/limit
> set as well (for example if the rows you want are late in the
> table it's going to underestimate the final cost I think.)
Hmm, I don't if it would be related, but the data only grows.
Additionally, we (about a week ago) migrated all of this data
(via pg_dump/pg_restore) from 7.1.3. Perhaps this is related?
Thanks again for all the help!
-ron