>
> Well, for starters you're looking at an estimation miss. The
> exhaustive search found the 'cheaper' plan than what geqo came up
> with, but that did not correlate to execution time. This is a common
> and frustrating problem. Generally to try and avoid it it's good to
> avoid things in tabl
I've encountered a query with 11 joins whose execution time (i.e., the time
not taken up by planning) is significantly faster with geqo on rather than
off. This is surprising to me and seems like it might be a bug in the
planner, so I am posting it here rather than to -performance.
The query is be
