Re: The science of optimization in practical terms?

From: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, decibel <decibel(at)decibel(dot)org>, Greg Smith <gsmith(at)gregsmith(dot)com>, Grzegorz Jaskiewicz <gj(at)pointblue(dot)com(dot)pl>, Bernd Helmle <mailings(at)oopsware(dot)de>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: The science of optimization in practical terms?
Date: 2009-02-18 17:33:38
Message-ID: 1234978418.1775.13.camel@jd-laptop.pragmaticzealot.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Sam Mason 2009-02-18 17:46:11 Re: Multi calendar system for pgsql
Previous Message Robert Haas 2009-02-18 17:21:30 Re: graph representation of data structures in optimizer