Yeah, the problem is when I test large join, the plan considered by geqo is large than path. (3000+ vs 500+). However, the time used in optimizer of geqo is 1/4 of path. By the way, I use the same query.
Another thing is for the join of 2 tables, geqo consider 60-90 plans.
In general, I think for large join, geqo consider less plans than path, am I right?
2009/10/13 Tom Lane
<tgl@sss.pgh.pa.us>> Is it a reasonable idea to add a counter to set_cheapest?
You can try it but I think you'll find it's not terribly useful.
That will effectively just give you a count of the number of join
combinations that were considered (plus the number of base relations).
regards, tom lane
