Re: Hints (was Poor performance using CTE)
От | Joe Conway |
---|---|
Тема | Re: Hints (was Poor performance using CTE) |
Дата | |
Msg-id | 50AD0EA0.7070009@joeconway.com обсуждение исходный текст |
Ответ на | Re: Hints (was Poor performance using CTE) (Heikki Linnakangas <hlinnakangas@vmware.com>) |
Ответы |
Re: Hints (was Poor performance using CTE)
|
Список | pgsql-performance |
On 11/21/2012 08:05 AM, Heikki Linnakangas wrote: > Rather than telling the planner what to do or not to do, I'd much rather > have hints that give the planner more information about the tables and > quals involved in the query. A typical source of bad plans is when the > planner gets its cost estimates wrong. So rather than telling the > planner to use a nested loop join for "a INNER JOIN b ON a.id = b.id", > the user could tell the planner that there are only 10 rows that match > the "a.id = b.id" qual. That gives the planner the information it needs > to choose the right plan on its own. That kind of hints would be much > less implementation specific and much more likely to still be useful, or > at least not outright counter-productive, in a future version with a > smarter planner. > > You could also attach that kind of hints to tables and columns, which > would be more portable and nicer than decorating all queries. I like this idea, but also think that if we have a syntax to allow hints, it would be nice to have a simple way to ignore all hints (yes, I suppose I'm suggesting yet another GUC). That way after sprinkling your SQL with hints, you could easily periodically (e.g. after a Postgres upgrade) test what would happen if the hints were removed. Joe -- Joe Conway credativ LLC: http://www.credativ.us Linux, PostgreSQL, and general Open Source Training, Service, Consulting, & 24x7 Support
В списке pgsql-performance по дате отправления: