From: Andrew Sullivan <ajs@crankycanuck.ca>
To: pgsql-hackers@postgresql.org
To: pgsql-performance@postgresql.org
Subject: Re: [HACKERS] Hints proposal
Date: Thu, 12 Oct 2006 15:03:47 -0400
Message-ID: <20061012190347.GD29203@phlogiston.dyndns.org> (raw)
In-Reply-To: <b42b73150610121121o50c2b082l2b13d38fc3e00820@mail.gmail.com>
References: <20061012151439.GT28647@nasby.net>
<10866.1160667752@sss.pgh.pa.us>
<20061012162525.GF28647@nasby.net>
<20061012174503.GA29203@phlogiston.dyndns.org>
<b42b73150610121121o50c2b082l2b13d38fc3e00820@mail.gmail.com>
On Thu, Oct 12, 2006 at 02:21:55PM -0400, Merlin Moncure wrote:
> third way: to solve the problem of data (especially constants) not
> being available to the planner at the time the plan was generated.
> this happens most often with prepared statements and sql udfs. note
> that changes to the plan generation mechanism (i think proposed by
> peter e a few weeks back) might also solve this.
You're right about this, but you also deliver the reason why we don't
need hints for that: the plan generation mechanism is a better
solution to that problem. It's this latter thing that I keep coming
back to. As a user of PostgreSQL, the thing that I really like about
it is its pragmatic emphasis on correctness. In my experience, it's
a system that feels very UNIX-y: there's a willingness to accept
"80/20" answers to a problem in the event you at least have a way to
get the last 20, but the developers are opposed to anything that
seems really kludgey.
In the case you're talking about, it seems to me that addressing the
problems where they come from is a better solution that trying to
find some way to work around them. And most of the use-cases I hear
for a statement-level hints system fall into this latter category.
A
--
Andrew Sullivan | ajs@crankycanuck.ca
Unfortunately reformatting the Internet is a little more painful
than reformatting your hard drive when it gets out of whack.
--Scott Morris
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: ajs@crankycanuck.ca, pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Hints proposal
In-Reply-To: <20061012190347.GD29203@phlogiston.dyndns.org>
* 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