> -----Original Message-----
> From: pgsql-sql-owner@hub.org [mailto:pgsql-sql-owner@hub.org]On Behalf
> Of Tom Lane
>
[snip]
>
> 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
calculation.
Regards.
Hiroshi Inoue
Inoue@tpf.co.jp
