mladen.gogala@vmsinfo.com (Mladen Gogala) writes:
> Hints are not even that complicated to program. The SQL parser should
> compile the list of hints into a table and optimizer should check
> whether any of the applicable access methods exist in the table. If it
> does - use it. If not, ignore it. This looks to me like a
> philosophical issue, not a programming issue.
It's worth looking back to what has already been elaborated on in the
ToDo.
http://wiki.postgresql.org/wiki/Todo
-----------------------------------
Optimizer hints (not wanted)
Optimizer hints are used to work around problems in the optimizer and
introduce upgrade and maintenance issues. We would rather have the
problems reported and fixed. We have discussed a more sophisticated
system of per-class cost adjustment instead, but a specification remains
to be developed.
-----------------------------------
The complaint is that kludging hints into a particular query attacks the
problem from the wrong direction.
The alternative recommended is to collect some declarative information,
that *won't* be part of the query, that *won't* be processed by the
parser, and that *won't* kludge up the query with information that is
liable to turn into crud over time.
Tom Lane was pretty specific about some kinds of declarative information
that seemed useful:
<http://archives.postgresql.org/pgsql-hackers/2006-10/msg00663.php>
On Jeapordy, participants are expected to phrase one's answers in the
form of a question, and doing so is rewarded.
Based on the presence of "query hints" on the Not Wanted portion of the
ToDo list, it's pretty clear that participants here are expected to
propose optimizer hints in ways that do NOT involve decorating queries
with crud. You'll get a vastly friendlier response if you at least make
an attempt to attack the problem in the "declarative information"
fashion.
Perhaps we're all wrong in believing that pushing query optimization
information into application queries by decorating the application with
hints, is the right idea but it's a belief that certainly seems to be
regularly agreed upon by gentle readers.
--
"cbbrowne","@","linuxdatabases.info"
The people's revolutionary committee has decided that the name "e" is
retrogressive, unmulticious and reactionary, and has been flushed.
Please update your abbrevs.
