From: Brian Hurt <bhurt@janestcapital.com>
To: postgres performance list <pgsql-performance@postgresql.org>
Subject: Re: Hints proposal
Date: Mon, 16 Oct 2006 11:36:23 -0400
Message-ID: <4533A6F7.7010708@janestcapital.com> (raw)
In-Reply-To: <1161005266.28751.145.camel@coppola.muc.ecircle.de>
References: <78ED28FACE63744386D68D8A9D1CF5D4209CBF@MAIL.corp.lumeta.com>
<4532D17B.20106@modgraph-usa.com>
<45337C56.8000209@paradise.net.nz>
<1161005266.28751.145.camel@coppola.muc.ecircle.de>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: bhurt@janestcapital.com
Subject: Re: Hints proposal
In-Reply-To: <4533A6F7.7010708@janestcapital.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox