Re: BUG #7619: Query cost estimate appears to not use n_distinct setting

Tom Lane wrote:

> plus some not-very-large CPU-per-tuple charges

In my experience, cpu_tuple_cost should be higher. I've often had to
boost it to get good plans for a wide mix of queries in a load.
Doubling it to 0.02 is often not enough to get good plans. I've taken
it to 0.05 with production workloads without ill effect, but
personally have not seen further improvements beyond the plans I got
at 0.03. Among other things, this setting tends to make the ratio
between random_page_cost and seq_page_cost somewhat less sensitive;
although I still find it best to take them both down to 0.1 for fully
cached workloads, along with the cpu_tuple_cost boost.

I think we should raise the default for cpu_tuple_cost, but have been
reluctant to suggest it based on just my personal experiences. Has
anyone else found this useful?

-Kevin