Re: patch for geqo tweaks

From: Nathan Wagner <nw+pg(at)hydaspes(dot)if(dot)org>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: patch for geqo tweaks
Date: 2015-11-06 18:27:07
Message-ID: 20151106182707.GB8543@granicus.if.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2015-11-06 18:37:59 Re: Transactions involving multiple postgres foreign servers
Previous Message Nathan Wagner 2015-11-06 17:56:31 Re: patch for geqo tweaks