Re: Simple join optimized badly?
От | Jim C. Nasby |
---|---|
Тема | Re: Simple join optimized badly? |
Дата | |
Msg-id | 20061009223030.GW72517@nasby.net обсуждение исходный текст |
Ответ на | Re: Simple join optimized badly? (Tobias Brox <tobias@nordicbet.com>) |
Ответы |
Re: Simple join optimized badly?
Re: Simple join optimized badly? |
Список | pgsql-performance |
On Mon, Oct 09, 2006 at 11:33:03PM +0200, Tobias Brox wrote: > [Jim C. Nasby - Mon at 04:18:27PM -0500] > > I can agree to that, but we'll never get any progress so long as every > > time hints are brought up the response is that they're evil and should > > never be in the database. I'll also say that a very simple hinting > > language (ie: allowing you to specify access method for a table, and > > join methods) would go a huge way towards enabling app developers to get > > stuff done now while waiting for all these magical optimizer > > improvements that have been talked about for years. > > Just a comment from the side line; can't the rough "set > enable_seqscan=off" be considered as sort of a hint anyway? There have > been situations where we've actually had to resort to such crud. > > Beeing able to i.e. force a particular index is something I really > wouldn't put into the application except for as a very last resort, > _but_ beeing able to force i.e. the use of a particular index in an > interactive 'explain analyze'-query would often be ... if not outright > useful, then at least very interessting. One of the big problems with doing set enable_...=off is that there's no way to embed that into something like a view, so you're almost forced into putting into the application code itself, which makes matters even worse. If you could hint this within a query (maybe even on a per-table level), you could at least encapsulate that into a view. -- Jim Nasby jim@nasby.net EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
В списке pgsql-performance по дате отправления: