> "Mark Woodward" <pgsql@mohawksoft.com> writes:
>> I would say that a "simpler" planner with better hints
>> will always be capable of creating a better query plan.
>
> This is demonstrably false: all you need is an out-of-date hint, and
> you can have a worse plan.
That doesn't make it false, it makes it higher maintenance. Hints are
understood to require maintenance.
>
> The argument against hints is not about whether someone could knock
> together a crappy hint facility and be able to get some use out of it.
> It is about how much work it would take to design a *good* hint facility
> that makes it easy to maintain hints that are robust in the face of data
> and query changes. If someone were to sit down and design and build
> such a thing, it'd very likely get accepted into core Postgres --- but
> personally, I think the equivalent amount of effort would be better
> spent on improving the planner and the statistics.
While it is always true that something can be improved, there comes a
point where work outweighs benefits. I can't say that the planner is at
that point, but I think that isn't even an issue.
The notion of hints would probably one of the biggest steps toward
improving the planner. Like I said, it is inarguable that there will
always be queries that the planner can not execute efficiently based on
the statistics gathered by analze. Since that number must be greater than
zero, some methodology to deal with it should be created.
>
> As Josh already noted, Oracle-like hints are pretty likely to get
> rejected ... not only because of doubts about their true usefulness,
> but out of fear of falling foul of some Oracle patent or other.
Well, if it would get rejected if it looked like Oracle, assuming you
would probably be one of the people rejecting it, what do you envision as
not being rejected?