Re: BUG #7619: Query cost estimate appears to not use n_distinct setting - Mailing list pgsql-bugs

From Kevin Grittner
Subject Re: BUG #7619: Query cost estimate appears to not use n_distinct setting
Date
Msg-id 20121025015648.306900@gmx.com
Whole thread Raw
List pgsql-bugs
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

pgsql-bugs by date:

Previous
From: Merlin Moncure
Date:
Subject: Re: Introducing floating point cast into filter drastically changes row estimate
Next
From: Dmitrijs Ledkovs
Date:
Subject: Fails to build from source with multiarched python3.3 on Debian-like systems