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 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs