On Wed, 2009-02-18 at 07:50 -0500, Robert Haas wrote: > (Now it appears that Josh is having problems that are caused by > overestimating the cost of a page fetch, perhaps due to caching > effects. Those are discussed upthread, and I'm still interested to > see whether we can arrive at any sort of consensus about what might be > a reasonable approach to attacking that problem. My own experience > has been that this problem is not quite as bad, because it can throw > the cost off by a factor of 5, but not by a factor of 800,000, as in > my example of three unknown expressions with a combined selectivity of > 0.1.) >
Well a very big problem with any solution is that we are creating a solution for a 2% problem. 98% of the postgresql installations out there will never need to adjust cpu_tuple_cost, cpu_index_tuple_cost, cpu_operator_cost, random_page_cost etc... They can get by just fine with a tweak to shared_buffers, work_mem, effective_cache_size and default_statistics_target. What I think should happen is to do some testing one "normal" installs and see if upping those parameters to .5 (or other amount) hinders those 98% installs. If it doesn't hinder those then we should up the default and walk away. Joshua D. Drake > ...Robert > -- PostgreSQL - XMPP: jdr...@jabber.postgresql.org Consulting, Development, Support, Training 503-667-4564 - http://www.commandprompt.com/ The PostgreSQL Company, serving since 1997 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
