Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov wrote:
>> Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>
>>> if we think it's reasonable for people to want to explicitly
>>> specify the join order
>>
>> Regardless of the syntax (GUC or otherwise), that is an optimizer
>> hint. I thought we were trying to avoid those.
>
> I guess my point is that there's not a lot of obvious benefit in
> allowing the functionality to exist but handicapping it so that it's
> useful in as few cases as possible. If the consensus is that we
> want half a feature (but not more or less than half), that's OK with
> me, but it's not obvious to me why we should choose to want that.
Ever since I've been following these lists, there have been a pretty
steady dribble of requests for optimizer hints of one type or another.
The standard response has always been, "If you have a query which is
optimizing poorly, show us, and we'll try to fix the optimizer so that
it doesn't need hints to do a good job." The enable_* GUCs
effectively *are* optimizer hints, but they are strongly discouraged
for anything but diagnostic purposes. I guess I don't see any reason
to consider this issue as being different.
If implementing them this way seems to handicap them, I guess that's
probably to discourage their use, which seems reasonable to me; I bet
people would shoot themselves in the foot much more often than they
would help themselves with such options, we'd lose information which
might help to improve the optimizer, and the list would probably get a
pretty steady stream of "slow queries" which would turn out to be
(after digging deep enough) caused by people using hints that caused a
sub-optimal plan to be chosen.
-Kevin