From: Andrew Sullivan <ajs@crankycanuck.ca>
To: pgsql-hackers@postgresql.org
Subject: Re: [PERFORM] Hints proposal
Date: Fri, 13 Oct 2006 10:09:15 -0400
Message-ID: <20061013140915.GC31912@phlogiston.dyndns.org> (raw)
In-Reply-To: <E1539E0ED7043848906A8FF995BDA579016A0981@m0143.s-mxs.net>
References: <20061012174503.GA29203@phlogiston.dyndns.org>
<E1539E0ED7043848906A8FF995BDA579016A0981@m0143.s-mxs.net>
On Fri, Oct 13, 2006 at 10:41:36AM +0200, Zeugswetter Andreas ADI SD wrote:
> Can you give us an example that had such a monstrous effect in Oracle,
> other than that the hint was a mistake in the first place ?
Of course the hint was a mistake in the first place; the little story
I told was exactly an example of such a case. The hint shouldn't
have been put in place at the beginning; instead, the root cause
should have been uncovered. It was not, the DBA added a hint, and
later that hint turned out to have unfortunate consequences for
some other use case. And it's a long-term monstrosity, remember,
not a short one: the problem is in maintenance overall.
This is a particularly sensitive area for PostgreSQL, because the
planner has been making giant leaps forward with every release.
Indeed, as Oracle's planner got better, the hints people had in place
sometimes started to cause them to have to re-tune everything. My
Oracle-using acquaintances tell me this has gotten better in recent
releases; but in the last two days, one person pointed out that hints
are increasingly relied on by one part of Oracle, even as another
Oracle application insists that they never be used. That's exactly
the sort of disagreement I'd expect to see when people have come to
rely on what is basically a kludge in the first place.
And remember, the places where PostgreSQL is getting used most
heavily are still the sort of environments where people will take a
lot of short cuts to achieve an immediate result, and be annoyed when
that short cut later turns out to have been expensive. Postgres will
get a black eye from that ("Too hard to manage! Upgrades cause all
sorts of breakage!").
A
--
Andrew Sullivan | ajs@crankycanuck.ca
The plural of anecdote is not data.
--Roger Brinner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: ajs@crankycanuck.ca, pgsql-hackers@postgresql.org
Subject: Re: [PERFORM] Hints proposal
In-Reply-To: <20061013140915.GC31912@phlogiston.dyndns.org>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox