> And the user maintenance of updating those hints for every release of
> PostgreSQL as we improve the database engine.

I don't think so. Basically an optimizer hint simply raises or lowers the cost
of an index, mandates a certain join order, allows or disallows a seq scan ...
Imho it is not so far from the things people currently do with the set seq_scan=
type of commands.
(I don't think actually giving a certain plan is a good idea)

A good optimizer hint system would imho not circumvent the optimizer, but only
give it hints. The hints should be very specifically aimed, like "an index on column x"
is going to be more expensive than you (the optimizer) think, if used with this query.
like: select /*+ avoid_index(atab atab_x0) */ * from atab ...

> > The people who are actually doing the work think their time is more
> > usefully spent on improving the planner's intelligence than on devising
> > ways to override it.

The subject of this mail and "override it" imho goes too far, I would like to
be able to give advice in the form of hints to the optimizer.

> One consistent problem is the planner not being able to handle this or
> that scenario. At this stage, the *best* way to improve the planner is to
> add the ability to place hints in the plan.
^^^^ sql statement

I agree.

Andreas

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend