Skip site navigation (1) Skip section navigation (2)

pgsql: Rewrite GEQO's gimme_tree function so that it always finds a

From: tgl(at)postgresql(dot)org (Tom Lane)
To: pgsql-committers(at)postgresql(dot)org
Subject: pgsql: Rewrite GEQO's gimme_tree function so that it always finds a
Date: 2009-07-19 21:00:43
Message-ID: 20090719210043.76ADF75331E@cvs.postgresql.org (view raw or flat)
Thread:
Lists: pgsql-committerspgsql-hackers
Log Message:
-----------
Rewrite GEQO's gimme_tree function so that it always finds a legal join
sequence, even when the input "tour" doesn't lead directly to such a sequence.
The stack logic that was added in 2004 only supported cases where relations
that had to be joined to each other (due to join order restrictions) were
adjacent in the tour.  However, relying on a random search to figure that out
is tremendously inefficient in large join problems, and could even fail
completely (leading to "failed to make a valid plan" errors) if
random_init_pool ran out of patience.  It seems better to make the
tour-to-plan transformation a little bit fuzzier so that every tour can form
a legal plan, even though this means that apparently different tours will
sometimes yield the same plan.

In the same vein, get rid of the logic that knew that tours (a,b,c,d,...)
are the same as tours (b,a,c,d,...), and therefore insisted the latter
are invalid.  The chance of generating two tours that differ only in
this way isn't that high, and throwing out 50% of possible tours to
avoid such duplication seems more likely to waste valuable genetic-
refinement generations than to do anything useful.

This leaves us with no cases in which geqo_eval will deem a tour invalid,
so get rid of assorted kluges that tried to deal with such cases, in
particular the undocumented assumption that DBL_MAX is an impossible
plan cost.

This is all per testing of Robert Haas' lets-remove-the-collapse-limits
patch.  That idea has crashed and burned, at least for now, but we still
got something useful out of it.

It's possible we should back-patch this change, since the "failed to make a
valid plan" error can happen in existing releases; but I'd rather not until
it has gotten more testing.

Modified Files:
--------------
    pgsql/src/backend/optimizer/geqo:
        geqo_eval.c (r1.89 -> r1.90)
        (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/optimizer/geqo/geqo_eval.c?r1=1.89&r2=1.90)
        geqo_main.c (r1.57 -> r1.58)
        (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/optimizer/geqo/geqo_main.c?r1=1.57&r2=1.58)
        geqo_pool.c (r1.34 -> r1.35)
        (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/optimizer/geqo/geqo_pool.c?r1=1.34&r2=1.35)
        geqo_recombination.c (r1.16 -> r1.17)
        (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/optimizer/geqo/geqo_recombination.c?r1=1.16&r2=1.17)

Responses

pgsql-hackers by date

Next:From: Robert HaasDate: 2009-07-19 21:55:38
Subject: Re: generic explain options v3 - RR Review
Previous:From: Bruce MomjianDate: 2009-07-19 19:18:36
Subject: Problem with psql backward compatibility

pgsql-committers by date

Next:From: User AndrewsnDate: 2009-07-19 22:44:21
Subject: hstore-new - hstore-new: helps to update this file too.
Previous:From: Tom LaneDate: 2009-07-19 20:32:56
Subject: pgsql: Fix a thinko in join_is_legal: when we decide we can implement a

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group