From: | "Merlin Moncure" <mmoncure(at)gmail(dot)com> |
---|---|
To: | "Andrew Sullivan" <ajs(at)crankycanuck(dot)ca> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [PERFORM] Hints proposal |
Date: | 2006-10-12 18:21:55 |
Message-ID: | b42b73150610121121o50c2b082l2b13d38fc3e00820@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-performance |
On 10/12/06, Andrew Sullivan <ajs(at)crankycanuck(dot)ca> wrote:
> On Thu, Oct 12, 2006 at 11:25:25AM -0500, Jim C. Nasby wrote:
> > Yes, but it does one key thing: allows DBAs to fix problems *NOW*. See
> > also my comment below.
>
> If I may argue in the other direction, speaking as one whose career
> (if we may be generous enough to call it that) has been pretty much
> exclusively on the operations end of things, I think that's an awful
> idea.
>
> There are two ways that quick-fix solve-the-problem-now hints are
> going to be used. One is in the sort of one-off query that a DBA has
third way: to solve the problem of data (especially constants) not
being available to the planner at the time the plan was generated.
this happens most often with prepared statements and sql udfs. note
that changes to the plan generation mechanism (i think proposed by
peter e a few weeks back) might also solve this.
In a previous large project I had to keep bitmap scan and seqscan off
all the time because of this problem (the project used a lot of
prepared statements).
or am i way off base here?
merlin
From | Date | Subject | |
---|---|---|---|
Next Message | D'Arcy J.M. Cain | 2006-10-12 18:24:22 | Re: New version of money type |
Previous Message | Tom Lane | 2006-10-12 18:17:33 | Re: New version of money type |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-10-12 18:25:09 | Re: Scrub one large table against another |
Previous Message | Brendan Curran | 2006-10-12 18:05:04 | Re: Scrub one large table against another |