Re: Why we don't want hints

Поиск
Список
Период
Сортировка
От Josh Berkus
Тема Re: Why we don't want hints
Дата
Msg-id 4D585B4C.5020602@agliodbs.com
обсуждение исходный текст
Ответ на Re: Why we don't want hints  (Rob Wultsch <wultsch@gmail.com>)
Ответы Re: Why we don't want hints  (Scott Marlowe <scott.marlowe@gmail.com>)
Список pgsql-performance
I've wordsmithed Chris's changes some, and then spun off a completely
separate page for Hints discussion, since the NotToDo item was becoming
too long.

> Something like this syntax?:
>
> JOIN WITH (correlation_factor=0.3)

Please, NO!

This is exactly the kind of hint that I regard as a last resort if we
run out of implementation alternatives.  Any hint which gets coded into
the actual queries becomes a *massive* maintenance and upgrade headache
thereafter.  If we're implementing a hint alternative, we should look at
stuff in this priority order:

1. Useful tuning of additional cost parameters by GUC (i.e.
cursor_tuple_fraction)
2. Modifying cost parameters on database *objects* (i.e. "ndistinct=500")
3. Adding new parameters to modify on database objects (i.e.
"distribution=normal(1.5,17)","new_rows=0.1")
4. Query hints (if all of the above fails to give fixes for some tested
problem)

> Where exactly are the problems with other systems noted? Most other
> systems have this option so saying "They have problems" is a giant cop
> out.

I've put my list down:
http://wiki.postgresql.org/wiki/OptimizerHintsDiscussion#Problems_with_existing_Hint_stystems

--
                                  -- Josh Berkus
                                     PostgreSQL Experts Inc.
                                     http://www.pgexperts.com

В списке pgsql-performance по дате отправления:

Предыдущее
От: Rob Wultsch
Дата:
Сообщение: Re: Why we don't want hints
Следующее
От: sergey
Дата:
Сообщение: choosing the right RAID level for PostgresQL database