Re: Overriding the optimizer

Поиск
Список
Период
Сортировка
От Craig A. James
Тема Re: Overriding the optimizer
Дата
Msg-id 43A25372.8090706@modgraph-usa.com
обсуждение исходный текст
Ответ на Re: Overriding the optimizer  (Kevin Brown <kevin@sysexperts.com>)
Ответы Re: Overriding the optimizer  (Kevin Brown <kevin@sysexperts.com>)
Re: Overriding the optimizer  (Bruno Wolff III <bruno@wolff.to>)
Список pgsql-performance
Kevin Brown wrote:
>>Hints are dangerous, and I consider them a last resort.
>
> If you consider them a last resort, then why do you consider them to
> be a better alternative than a workaround such as turning off
> enable_seqscan, when all the other tradeoffs are considered?

If I understand enable_seqscan, it's an all-or-nothing affair.  Turning it off turns it off for the whole database,
right? The same is true of all of the planner-tuning parameters in the postgres conf file.  Since the optimizer does a
goodjob most of the time, I'd hate to change a global setting like this -- what else would be affected?  I could try
this,but it would make me nervous to alter the whole system to fix one particular query. 

> If your argument is that planner hints would give you finer grained
> control, then the question is whether you'd rather the developers
> spend their time implementing planner hints or improving the planner.

I agree 100% -- I'd much prefer a better planner.  But when it comes down to a do-or-die situation, you need a hack,
somesort of workaround, to get you working *today*. 

Regards,
Craig

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

Предыдущее
От: Kevin Brown
Дата:
Сообщение: Re: Overriding the optimizer
Следующее
От: Kevin Brown
Дата:
Сообщение: Re: How much expensive are row level statistics?