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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Re: [COMMITTERS] pgsql: Rewrite GEQO's gimme_tree function so that it always finds a
Дата
Msg-id 2407.1259371952@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Re: [COMMITTERS] pgsql: Rewrite GEQO's gimme_tree function so that it always finds a  (marcin mank <marcin.mank@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Greg Smith
Дата:
Сообщение: Re: [PATCH 4/4] Add tests to dblink covering use of COPY TO FUNCTION
Следующее
От: Jeff Davis
Дата:
Сообщение: Re: operator exclusion constraints