On Fri, 22 Sep 2000, Tom Lane wrote:
> indexscans; the current code may have overcorrected a shade, but I think
> it's closer to reality than 6.5 was.
>
> As Hiroshi already commented, the difference in results suggests that
> the desired data is very nonuniformly scattered in the table. 7.0
> computes cost estimates on the assumption that the target data is
> uniformly scattered. For a sufficiently nonselective WHERE condition
> (ie, one that the planner thinks will match a large fraction of the
> table's rows) it looks better to do a seqscan and pick up the matching
> rows than to follow the index pointers. Adding a LIMIT doesn't change
> this equation.
>
> I like Hiroshi's recommendation: add an ORDER BY to help favor the
> indexscan.
Yeah, I didn't notice the lack of the order by when I responded. I
forget that order by isn't required to use limit since it's fairly
ugly to not use one ("What, you wanted to get a implementation defined
effectively random 10 rows?")
