> -----Original Message-----
> From: pgsql-sql-owner(at)hub(dot)org [mailto:pgsql-sql-owner(at)hub(dot)org]On Behalf
> Of Tom Lane
> This seems to point up (once again) the deficiency of assuming that
> the most-common value in the table is a good guide to the frequency
> of typical values. You showed that host_id = 446 occurs in 2.8% of
> the rows in this table; a search for 446 very probably would be faster
> as a seqscan than as an indexscan (you might care to try it and see).
> But that's probably a statistical outlier that's not got much to do
> with the frequency of typical values in the table.
> The only really good answer to this problem is to collect more-detailed
> statistics in VACUUM ANALYZE, which I hope to see us doing in a release
> or so.
For example we could count up distinct values for the first column of an
index by scanning its index relation.
> In the meantime I am wondering about deliberately skewing the
> cost model in favor of indexscans, because I sure haven't heard many
> complaints about erroneous selection of indexscans...
> One way to put a thumb on the scales is to reduce the value of the SET
> variable random_page_cost. The default value is 4.0, which seems to
> correspond more or less to reality, but reducing it to 3 or so would
> shift the planner pretty nicely in the direction of indexscans.
Or how about changing current fudge factor ?
For example,from 0.5 to 0.2 which is the fudge factor of attdisbursion
In response to
pgsql-sql by date
|Next:||From: Mikheev, Vadim||Date: 2000-05-25 14:29:58|
|Subject: RE: Use of index in 7.0 vs 6.5 |
|Previous:||From: Tom Lane||Date: 2000-05-25 06:14:38|
|Subject: Re: Use of index in 7.0 vs 6.5 |