On Fri, Nov 14, 2008 at 10:50 AM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.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