Re: [PERFORM] Hints proposal

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

In response to

Responses

Browse pgsql-hackers by date

  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

Browse pgsql-performance by date

  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