Re: Overriding the optimizer

Craig A. James wrote:
> 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.

Nope. What's in the conf file are the defaults. You can change them
on a per-connection basis, via the SET command. Thus, before doing
your problematic query:

SET enable_seqscan = off;

and then, after your query is done,

SET enable_seqscan = on;

> >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, some sort of workaround, to get
> you working *today*.

And that's why I was asking about workarounds versus planner hints. I
expect that the situations in which the planner gets things wrong
*and* where there's no workaround are very rare indeed.

--
Kevin Brown kevin(at)sysexperts(dot)com