On Thu, 20 Jun 2002, Gregory Wood wrote:
> I guess the best way to approach that particular tuning problem is to find a
> query where the estimated row numbers is close to the actual page numbers
> and then try different values until the random page reads start to become
> slower than the sequential scan. Fun fun.
>
> Of course if PostgreSQL were estimating the number of rows correctly, that
> would be less of a problem. Seems that our data is throwing off the
> statistics... we have some values that appear tens of thousands of times and
> others that appear only a few times, with a few values (such as the example
> I sent) in between. Perhaps it's time to look at TABLE SET STATISTICS...
Yeah. Since the number of the high frequency values is greater than the
number it keeps track of, you're in the same general boat as the earlier
statistics wierdnesses. It's really easy to play with the set statistics
though. :)