Re: Hooking at standard_join_search (Was: Re: Foreign join pushdown vs EvalPlanQual) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Hooking at standard_join_search (Was: Re: Foreign join pushdown vs EvalPlanQual)
Date
Msg-id 6631.1441338689@sss.pgh.pa.us
Whole thread Raw
In response to Re: Hooking at standard_join_search (Was: Re: Foreign join pushdown vs EvalPlanQual)  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Hooking at standard_join_search (Was: Re: Foreign join pushdown vs EvalPlanQual)  (Robert Haas <robertmhaas@gmail.com>)
List 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 by date:

Previous
From: "Shulgin, Oleksandr"
Date:
Subject: Re: On-demand running query plans using auto_explain and signals
Next
From: Michael Paquier
Date:
Subject: Re: Fwd: Core dump with nested CREATE TEMP TABLE