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 and queries that the database has difficulty planning or to crank statistics in specific cases.
RhodiumToad on #postgresql thinks it may be a different issue -- namely, the fact that there are various estimates of rows=1 when the actual number is higher. Increasing default_statistics_target to 1000 and 10000 seems to confirm this -- if anything, the query runs slower, and the plans look to be about the same. So I'm not convinced yet that it's not a bug. The better performance with geqo on is pretty consistent. I recognize that the query is complex, and I can try to simplify it, but it would be nice if its performance were not a matter of luck.
I've attached a file containing the original query and the EXPLAIN ANALYZE results for geqo on and default_statistics_target 100, geqo off and default_statistics_target 100, geqo on and default_statistics_target 10000, and geqo off and default_statistics_target 10000, showing that the increased statistics target doesn't help. (I figured it would be easier to read as an attachment because my email client automatically wraps long lines.)
