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 [EMAIL PROTECTED]
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
