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
Re: Overriding the optimizer |
Список | 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 по дате отправления: