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 tables
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
