Re: Simple postgresql.conf wizard

From: "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com>
To: "Heikki Linnakangas" <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: "Grzegorz Jaskiewicz" <gj(at)pointblue(dot)com(dot)pl>, "Pg Hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Simple postgresql.conf wizard
Date: 2008-11-14 15:53:10
Message-ID: 36e682920811140753j3c027926i3bf9811659f1c10b@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Nov 14, 2008 at 10:50 AM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
>> Oracle already thought of that a long time ago, which is why the plan
>> has to come out better for it to take effect.
>
> Huh? We would never willingly choose a worse plan, of course, but the point
> is that what looks like a better plan, with a smaller cost estimate, is
> sometimes actually worse.

Oracle bases it on cost and elapsed execution time.

>> As for bad plans, you
>> obviously haven't used Postgres in production enough to deal with it
>> continually changing plans for the worse due to index bloat, data
>> skew, phase of the moon, etc. :)
>
> You're right, I haven't, but yes I know that's a problem. We've chatted
> about that with Greg sometimes. It would be nice to have more stable plans.
> My favorite idea is to stop using the current relation size in the planner,
> and use the value snapshotted at ANALYZE instead. That way, the planner
> would be completely deterministic, based on the statistics. Then, we could
> have tools to snapshot the statistics, move them to a test system, store
> them, revert back to old statistics etc.

Yes, plan stability would be a Good Thing(tm) IMO.

--
Jonah H. Harris, Senior DBA
myYearbook.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message KaiGai Kohei 2008-11-14 15:58:19 Re: Updates of SE-PostgreSQL 8.4devel patches (r1197)
Previous Message Tom Lane 2008-11-14 15:51:57 Re: Block-level CRC checks