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
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 |