Re: Review remove {join,from}_collapse_limit, add enable_join_ordering
От | Robert Haas |
---|---|
Тема | Re: Review remove {join,from}_collapse_limit, add enable_join_ordering |
Дата | |
Msg-id | 603c8f070907161013o1c7d4dd0u45cf7fd907d18f0a@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Review remove {join,from}_collapse_limit, add enable_join_ordering (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: Review remove {join,from}_collapse_limit, add enable_join_ordering
|
Список | pgsql-hackers |
On Thu, Jul 16, 2009 at 12:49 PM, Andres Freund<andres@anarazel.de> wrote: > On Thursday 16 July 2009 17:59:58 Tom Lane wrote: >> Andres Freund <andres@anarazel.de> writes: >> > The default settings currently make it relatively hard to trigger geqo at >> > all. >> >> Yes, and that was intentional. One of the implications of what we're >> discussing here is that geqo would get used a lot more for "typical >> complex queries" (if there is any such thing as a typical one). So >> it's fully to be expected that the fallout would be pressure to improve >> geqo in various ways. >> >> Given that we are at the start of the development cycle, that prospect >> doesn't scare me --- there's plenty of time to fix whatever needs >> fixing. However, I am leaning to the feeling that I don't want to be >> putting people in a position where they have no alternative but to use >> geqo. So adjusting rather than removing the collapse limits is seeming >> like a good idea. > Hm. I see a, a bit more fundamental problem with geqo: > I tried several queries, and I found not a single one, where the whole > genetical process did any significant improvments to the 'worth'. > It seems that always the best variant out of the pool is either the path > choosen in the end, or at least the cost difference is _really_ low. Ouch. Did you insert some debugging code to get that information, or how did you come to that conclusion? ...Robert
В списке pgsql-hackers по дате отправления: