Received: from localhost (wm.hub.org [200.46.204.128])
	by postgresql.org (Postfix) with ESMTP id A14CC9FB2E8
	for <pgsql-performance-postgresql.org@postgresql.org>;
	Thu, 12 Oct 2006 12:26:32 -0300 (ADT)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.128]) (amavisd-new, port 10024)
	with ESMTP id 88748-09 for
	<pgsql-performance-postgresql.org@postgresql.org>;
	Thu, 12 Oct 2006 15:26:26 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-
Received: from nf-out-0910.google.com (nf-out-0910.google.com
 [64.233.182.188])
	by postgresql.org (Postfix) with ESMTP id 3331D9FB1DC
	for <pgsql-performance@postgresql.org>;
	Thu, 12 Oct 2006 12:26:25 -0300 (ADT)
Received: by nf-out-0910.google.com with SMTP id k26so547556nfc
	for <pgsql-performance@postgresql.org>;
	Thu, 12 Oct 2006 08:26:25 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
	h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
	b=e3bdj5lM0aMiXBZCfyirRPHXG6eNGPVG6ejLkW0LS2+E2OuXkvYsDi080P0OzfRZ8QxIM2cXxG+/6ColN+GudpC8dcBbVsBWUbvp48HRxGZ/CCZNsm9bXxCznP8Tylu5jNe9Dxk/3TbKpYzTVSwGElH8PYUGN6syPHPPQpVB2Q4=
Received: by 10.48.48.1 with SMTP id v1mr611707nfv;
	Thu, 12 Oct 2006 08:26:24 -0700 (PDT)
Received: by 10.49.41.6 with HTTP; Thu, 12 Oct 2006 08:26:24 -0700 (PDT)
Message-ID: <38242de90610120826l5328759bt41468644e54badae@mail.gmail.com>
Date: Thu, 12 Oct 2006 09:26:24 -0600
From: "Joshua Marsh" <icub3d@gmail.com>
To: pgsql-performance@postgresql.org
Subject: Re: Hints proposal
In-Reply-To: <20061012151439.GT28647@nasby.net>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_53353_15609176.1160666784879"
References: <20061012151439.GT28647@nasby.net>
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=0.2 tagged_above=0 required=5
	tests=DNS_FROM_RFC_ABUSE, HTML_MESSAGE, SPF_PASS
X-Spam-Level: 
X-Archive-Number: 200610/235
X-Sequence-Number: 21364

------=_Part_53353_15609176.1160666784879
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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.

------=_Part_53353_15609176.1160666784879
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

<div><span class="gmail_quote">On 10/12/06, <b class="gmail_sendername">Jim C. Nasby</b> &lt;<a href="mailto:jim@nasby.net">jim@nasby.net</a>&gt; wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Posting here instead of hackers since this is where the thread got<br>started...<br><br>The argument has been made that producing a hints system will be as hard
<br>as actually fixing the optimizer. There's also been clamoring for an<br>actual proposal, so here's one that (I hope) wouldn't be very difficult<br>to implemen.<br><br>My goal with this is to keep the coding aspect as simple as possible, so
<br>that implementation and maintenance of this isn't a big burden. Towards<br>that end, these hints either tell the planner specifically how to handle<br>some aspect of a query, or they tell it to modify specific cost<br>
estimates. My hope is that this information could be added to the<br>internal representation of a query without much pain, and that the<br>planner can then use that information when generating plans.</blockquote>
<div>&nbsp;</div>
<div>I've been following the last thread with a bit of interest.&nbsp; I like the proposal.&nbsp; It seems simple and easy to use.&nbsp; What is it about hinting that makes it so easily breakable with new versions?&nbsp; I don't have any experience with Oracle, so I'm not sure how they screwed logic like this up.&nbsp; 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.&nbsp; It will become painfully obvious to the developer if his hinting is broken.
</div><br>&nbsp;</div>

------=_Part_53353_15609176.1160666784879--