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@xxxxxxxxxxxxxx
