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: jdrake@jabber.postgresql.org Consulting, Development, Support, Training 503-667-4564 -
http://www.commandprompt.com/ The PostgreSQL Company, serving since 1997