Re: generalizing the planner knobs

Поиск
Список
Период
Сортировка
От Gregory Maxwell
Тема Re: generalizing the planner knobs
Дата
Msg-id e692861c0512011801v91461aepa007a93f02c5e68e@mail.gmail.com
обсуждение исходный текст
Ответ на Re: generalizing the planner knobs  ("Pollard, Mike" <mpollard@cincom.com>)
Ответы Re: generalizing the planner knobs  (Neil Conway <neilc@samurai.com>)
Re: generalizing the planner knobs  (Trent Shipley <tshipley@deru.com>)
Список pgsql-hackers
On 12/1/05, Pollard, Mike <mpollard@cincom.com> wrote:
> Optimizer hints were added because some databases just don't have a very
> smart optimizer.  But you are much better served tracking down cases in
> which the optimizer makes a bad choice, and teaching the optimizer how
> to make a better one.  That way, all users get the benefit of the fix.
> Remember, the purpose of SQL is to isolate the end user from having to
> care about how the data is retrieved; that is the RDBMS' problem.  (the
> other thing forgotten was that it was supposed to be a natural language.
> NVL.  Bah.)

The flipside there is that a good set of hinting options  may increase
the amount of detailed feedback we get from users on improvements
needed in the optimizer.  The current knobs are pretty blunt and don't
do as much as I'd like when trying to track down exactly where the
optimiser has gone wrong.

If we'd really like to avoid people using the knobs to rig queries,
how about making them only  work with explain analyze, useful for
debugging but not so useful for actual queries.


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [COMMITTERS] pgsql: Add comments about why errno is set to zero.
Следующее
От: Tom Lane
Дата:
Сообщение: Reducing relation locking overhead