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
