Re: Simple join optimized badly?

-- tom lane wrote ---------------------------------------------------------
"Jim C. Nasby" <jim(at)nasby(dot)net> writes:
> I'd rather have the ugly solution sooner rather than the elegant one
> later (if ever).

The trouble with that is that we couldn't ever get rid of it, and we'd
be stuck with backward-compatibility concerns with the first (over
simplified) design. It's important to get it right the first time,
at least for stuff that you know perfectly well is going to end up
embedded in application code.

regards, tom lane
---------------------------------------------------------------------------

I agree that it's important to get it right the first time. It's also
important that my queries use the right index NOW. It's no use to me if my
queries run efficiently in the next release when I am running those queries
right now.

Hints would allow me to do that.

What would it take for hints to be added to postgres? If someone designed a
hint system that was powerful and flexible, and offered to implement it
themselves, would this be sufficient? This would address the concerns of
having a "bad" hint system, and also the concern of time being better spent on
other things.

I want to know if the other objections to hints, such as hints being left
behind after an improvement to the optimizer, would also be an issue. I don't
see this objection as significant, as people are already using ad hoc hacks
where they would otherwise use hints. The other reason I don't accept this
objection is that people who care about performance will review their code
after every DBMS upgrade, and they will read the release notes :)