Message-ID: <4533A6F7.7010708@janestcapital.com>
Date: Mon, 16 Oct 2006 11:36:23 -0400
From: Brian Hurt <bhurt@janestcapital.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
MIME-Version: 1.0
To: postgres performance list <pgsql-performance@postgresql.org>
Subject: Re: Hints proposal
References: <78ED28FACE63744386D68D8A9D1CF5D4209CBF@MAIL.corp.lumeta.com>	
	<4532D17B.20106@modgraph-usa.com>
	<45337C56.8000209@paradise.net.nz>
	<1161005266.28751.145.camel@coppola.muc.ecircle.de>
In-Reply-To: <1161005266.28751.145.camel@coppola.muc.ecircle.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

I haven't weighed in on this because 1) I'm not a postgresql developer, 
and am firmly of the opinion that they who are doing the work get to 
decide how the work gets done (especially when you aren't paying them 
for the work), and 2) I don't have any experience as a developer with 
hints, and thus don't know any of the pluses or minuses.  I do, however, 
know my fellow developers.  As general rules:

1) If you give developers a feature, they will use it.  The implicit 
assumption seems to be that if you're given a feature, you've been given 
it for a good reason, use it whenever possible.  Therefor, any hints 
feature *will* be used widely an in "inappropriate" circumstances.  
Protestations that this wasn't what the feature was meant for will fall 
on deaf ears.

2) Taking away a feature is painfull.  Of course the developers will 
*say* that they're doing it in a portable way that'll be easy to change 
in the future, but we lie like cheap rugs.  This is is often just a case 
of stupidity and/or ignorance, but even the best developers can get 
caught- 99 out of 100 uses of the feature are portable and easy to 
update, it's #100 that's a true pain, and #100 was an accident, or a 
kludge to get the app out the door under shipping schedule, etc.  Taking 
away, or breaking, a feature then just becomes a strong disincentive to 
upgrade.

3) Developers are often astonishingly bad at predicting what is or is 
not good for performance.  A good example of this for databases is the 
assumption that index scans are always faster than sequential scans.  
The plan the programmer thinks they want is often not the plan the 
programmer really wants.  Especially considering generally the program 
has so many other things they're having to deal with (the "it's hard to 
remember you're out to drain the swamp when you're up to your ass in 
alligators" problem) that we generally don't have the spare brainpower 
left over for query optimization.  Thus the strong tendancy to want to 
adopt simple, rough and ready, mostly kinda true rules (like "index 
scans are always faster than sequential scans") about what is or is not 
good for performance.

Or, in shorter forms:
1) If you make it convient to use, expect it to be used a lot.  If it 
shouldn't be used a lot, don't make it convient.
2) Breaking features means that people won't upgrade.
3) Programmers are idiots- design accordingly.

Brian