Date: Tue, 17 Oct 2006 01:34:30 +1300
From: Mark Kirkwood <markir@paradise.net.nz>
Subject: Re: Hints proposal
In-reply-to: <4532D17B.20106@modgraph-usa.com>
To: "Craig A. James" <cjames@modgraph-usa.com>
Cc: pgsql-performance@postgresql.org
Message-id: <45337C56.8000209@paradise.net.nz>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7bit
User-Agent: Thunderbird 1.5.0.7 (X11/20061003)
References: <78ED28FACE63744386D68D8A9D1CF5D4209CBF@MAIL.corp.lumeta.com>
	<4532D17B.20106@modgraph-usa.com>

Craig A. James wrote:
>
> 
> 2. Hints
>   a) On a aesthetic/theoretical level, hints suck.  They're ugly and rude
>   b) On a practical level, introducing hints will cause short- and 
> long-term problems
>   c) Hints would help DBAs solve urgent problems for which there is no 
> other solution

Pretty good summary!

Maybe there should be a 2d), 2e) and 2f).

2d) Hints will damage the ongoing development of the optimizer by 
reducing or eliminating test cases for its improvement.
2e) Hints will divert developer resource away from ongoing development 
of the optimizer.
2f) Hints may demoralize the developer community - many of whom will 
have been attracted to Postgres precisely because this was a realm where 
crude solutions were discouraged.

I understand that these points may seem a bit 'feel-good' and intangible 
- especially for the DBA's moving to Pg from Oracle, but I think they 
illustrate the mindset of the Postgres developer community, and the 
developer community is, after all - the primary reason why Pg is such a 
good product.

Of course - if we can find a way to define 'hint like' functionality 
that is more in keeping with the 'Postgres way' (e.g. some of the 
relation level statistical additions as discussed), then some of 2d-2f) 
need not apply.

Best wishes

Mark