Re: Hooking at standard_join_search (Was: Re: Foreign join pushdown vs EvalPlanQual)

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Hooking at standard_join_search (Was: Re: Foreign join pushdown vs EvalPlanQual)
Дата
Msg-id 6631.1441338689@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Hooking at standard_join_search (Was: Re: Foreign join pushdown vs EvalPlanQual)  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Hooking at standard_join_search (Was: Re: Foreign join pushdown vs EvalPlanQual)  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, Sep 2, 2015 at 1:47 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Offhand I think that the
>> most likely way to build that text will be to examine the query's jointree
>> to see where c,d,e appear in it.  But in any case, that's a separate issue
>> and I fail to see how plopping the join search problem into the FDW's lap
>> would make it any easier.

> Yeah, I am not advocating for putting the hook in
> standard_join_search.  I'm explaining why I put it in
> add_paths_to_joinrel instead of, as I believe you were advocating, in
> make_join_rel prior to the big switch.

If you had a solution to the how-to-build-the-query-text problem,
and it depended on that hook placement, then your argument might
make some sense.  As is, you've entirely failed to convince me
that this placement is not wrong, wasteful, and likely to create
unnecessary API breaks for FDWs.

(Also, per my last message on the subject, *after* the switch
is what I think makes sense.)
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Shulgin, Oleksandr"
Дата:
Сообщение: Re: On-demand running query plans using auto_explain and signals
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Fwd: Core dump with nested CREATE TEMP TABLE