On Tue, 20 Feb 2001, Joseph Shraibman wrote:
> > That's because the estimate in this case was 50 and so it's estimating
> > that going through the index and checking the heap is faster than a
> > sequence scan. The *estimator* didn't use the index to figure that out,
> > it's just saying that the best plan to actually *run* the query uses
> > the index.
> > IIRC, There's something which is effectively :
> > estimated rows = <most common value's frequency>*<fraction>
> > I think fraction defaults to (is always?) 1/10 for the standard
> > index type. That's where the 50 comes from. And the frequency is
> > probably from the last vacuum analyze.
>
> Then it should do the same thing no matter what value I use, but when I
> do different searches in one case it estimates 50 when there are 16 and
> in the other it estimeates 502 where there are 502.
It knows enough to do the special case where you are searching for the
most common value. I'd guess that's what's happening on the 502.
I think it stores the most common value and the fraction of rows that
represents as of last vacuum analyze.
