On Fri, Nov 06, 2015 at 11:45:38AM -0500, Tom Lane wrote: > However, really the whole argument is moot, because I notice that > geqo_mutation() is only called in the "#ifdef CX" code path, which > we don't use.
I suppose someone could turn it on via a compiler define. > So there's little point in improving it. No, probably not. > (There's a fair amount of dead code in /geqo/, which I've never had > the energy to clean up, but maybe we should do that sometime. It > seems unlikely that anyone will ever be interested in experimenting > with the ifdef'ed-out code paths.) I also note that in src/backend/optimizer/path/allpaths.c there is a join_search_hook variable apparently intended for plugins (extensions?) to be able to control the search path optimizer. And the geqo code is AFAICT turned off by default anyway, so none of the code is used in probably the vast majority of systems, with standard_join_search() being called instead. Would it be worth either of removing at least the non-ERX portions of the geqo code, or removing the geqo code entirely (presumably with a deprecation cycle) and moving it to an extension? If there's any interest, I can work up a patch for either or both. There is only one test in the regression suite that turns on geqo that I could find. It's labeled "check for failure to generate a plan with multiple degenerate IN clauses" in join.sql. -- nw -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers