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:34:55
Message-ID: 36e682920811140734k778fa465lda0043b564bde0c1@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Nov 14, 2008 at 2:52 AM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
>> Other systems do it. For example, Oracle tracks column usage and
>> attempts to determine the optimal statistics for that column (based on
>> the queries that used it) on an iterative basis. We don't track
>> column usage at all, so that option wouldn't be quite that easy to
>> implement. Though, there are certain things ANALYZE would be able to
>> determine with a little help, such as knowing to collect more samples
>> for columns it finds extremely skewed data in.
>
> That kind of feedback loops are a bit dangerous. For starters, it would mean
> that your test system would behave differently than your production system,
> just because you run different queries on it. There's also all kinds of
> weird dynamic behaviors that could kick in. For example, a query could run
> fine for the first few hundred times, but then the analyzer notices that a
> certain column is being accessed frequently and decides to increase the
> stats target for it, which changes the plan, for worse. Usually the new plan
> would be better, but the planner isn't perfect.

Oracle already thought of that a long time ago, which is why the plan
has to come out better for it to take effect. 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. :)

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2008-11-14 15:35:38 xmlconcat(NULL) crash
Previous Message Peter Eisentraut 2008-11-14 15:28:53 Brittleness in regression test setup