On Thursday 16 July 2009 19:13:55 Robert Haas wrote:
> On Thu, Jul 16, 2009 at 12:49 PM, Andres Freund<and...@anarazel.de> wrote:
> > On Thursday 16 July 2009 17:59:58 Tom Lane wrote:
> >> Andres Freund <and...@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?
Yes, I enabled GEQO_DEBUG and added some more debugging output.  

Btw, a higher generation count does not change that.

Andres

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to