Re: Re: [COMMITTERS] pgsql: Rewrite GEQO's gimme_tree function so that it always finds a - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Re: [COMMITTERS] pgsql: Rewrite GEQO's gimme_tree function so that it always finds a
Date
Msg-id 2407.1259371952@sss.pgh.pa.us
Whole thread Raw
In response to Re: Re: [COMMITTERS] pgsql: Rewrite GEQO's gimme_tree function so that it always finds a  (marcin mank <marcin.mank@gmail.com>)
List pgsql-hackers
marcin mank <marcin.mank@gmail.com> writes:
> This is pretty off-topic, but if we had some upper bound on the cost
> of the complete plan, we could discard pieces of the plan that already
> cost more.

> One way to get the upper bound is to generate the plan in depth-first
> fashion, instead of the current breadth-first. Instead of bottom-up
> dynamic programming, employ memoization.

Well, the breadth-first approach also allows elimination of large parts
of the search space.  It's not immediately obvious to me that the above
would be better.  You should be able to try it if you want though ---
these days, there's even a hook to allow replacement of the join search
strategy at runtime.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Greg Smith
Date:
Subject: Re: [PATCH 4/4] Add tests to dblink covering use of COPY TO FUNCTION
Next
From: Jeff Davis
Date:
Subject: Re: operator exclusion constraints