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 <t...@sss.pgh.pa.us> > =?UTF-8?B?57qq5pmT5pum?= <sheep...@gmail.com> writes: > > 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 >
