Re: Hints proposal - Mailing list pgsql-performance

From Joshua Marsh
Subject Re: Hints proposal
Date
Msg-id 38242de90610120826l5328759bt41468644e54badae@mail.gmail.com
Whole thread Raw
In response to Hints proposal  ("Jim C. Nasby" <jim@nasby.net>)
Responses Re: Hints proposal
Re: Hints proposal
List pgsql-performance
On 10/12/06, Jim C. Nasby <jim@nasby.net> wrote:
Posting here instead of hackers since this is where the thread got
started...

The argument has been made that producing a hints system will be as hard
as actually fixing the optimizer. There's also been clamoring for an
actual proposal, so here's one that (I hope) wouldn't be very difficult
to implemen.

My goal with this is to keep the coding aspect as simple as possible, so
that implementation and maintenance of this isn't a big burden. Towards
that end, these hints either tell the planner specifically how to handle
some aspect of a query, or they tell it to modify specific cost
estimates. My hope is that this information could be added to the
internal representation of a query without much pain, and that the
planner can then use that information when generating plans.
 
I've been following the last thread with a bit of interest.  I like the proposal.  It seems simple and easy to use.  What is it about hinting that makes it so easily breakable with new versions?  I don't have any experience with Oracle, so I'm not sure how they screwed logic like this up.  Hinting to use a specific merge or scan seems fairly straight forward; if the query requests to use an index on a join, I don't see how hard it is to go with the suggestion.  It will become painfully obvious to the developer if his hinting is broken.

 

pgsql-performance by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Hints proposal
Next
From: Tom Lane
Date:
Subject: Re: Hints proposal