On 03/10/2014 03:16 PM, Kevin Grittner wrote: > I only have anecdotal evidence, though. I have seen it help dozens > of times, and have yet to see it hurt. That said, most people on > this list are probably capable of engineering a benchmark which > will show whichever result they would prefer. I would prefer to > hear about other data points based on field experience with > production systems. I haven't offered the trivial patch because > when I've raised the point before, there didn't seem to be anyone > else who had the same experience. It's good to hear that Andres > has seen this, too.
The problem with cpu_tuple_cost is that it's used in several places by the planner and makes it hard to model what the effect of any change would be. If we had a good general benchmark which actually gave the query planner a workout, we could come up with some reasonable default settings, but right now we can't. Back in 2004-2006 era, when CPU speeds had leapfrogged ahead of disk speeds (which were largely unchanged from 2000), I was routinely *lowering* cpu_tuple_cost (and cpu_index_tuple_cost) to get better plans. This was baked into early versions of Greenplum for that reason. So I'm not saying that we shouldn't change the default for cpu_tuple_cost. I'm saying that we currently don't have enough information on *when* and *how much* to change it. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
