On 2015/09/02 23:30, Tom Lane wrote:
> Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp> writes:
>> On 2015/08/01 23:25, Tom Lane wrote:
>>> In my vision you probably really only want one call per build_join_rel
>>> event (that is, per construction of a new RelOptInfo), not per
>>> make_join_rel event.
>> I'd vote for hooking at standard_join_search.
> I think that method would require the FDW to duplicate a whole lot of the
> join search mechanism, for not a whole lot of benefit. It's possible that
> there'd be value in doing some initial reconnaissance once we've examined
> all the baserels, so I'm not necessarily against providing a hook there.
> But if you have in mind that typical FDWs would actually create join paths
> at that point, consider that
>
> 1. The FDW would have to find all the combinations of its supplied
> relations (unless you are only intending to generate one path for the
> union of all such rels, which seems pretty narrow-minded from here).
>
> 2. The FDW would have to account for join_is_legal considerations.
>
> 3. The FDW would have to arrange for creation of joinrel RelOptInfo
> structures. While that's possible, the available infrastructure for it
> assumes that joinrels are built up from pairs of simpler joinrels, so
> you couldn't go directly to the union of all the FDW's rels anyway.
Maybe my explanation was not correct, but the hook placement I think is
just before the set_cheapest call for each joinrel in
standard_join_search, as you proposed in [1]. And I think that if that
joinrel contains only foreign tables that all belong to the same foreign
server, then we give the FDW a chance to consider producing pushed-down
joins for that joinrel, ie, remote joins for all the foreign tables
contained in that joinrel. So, there is no need for #2 and #3. Also I
think that would allow us to consider producing pushed-down joins for
all the legal combinations of foreign tables that belong to the same
foreign server, according to the dynamic-programming method, in
principle. I've not had a solution to the how-to-build-the-query-text
problem yet, though.
Best regards,
Etsuro Fujita
[1] http://www.postgresql.org/message-id/5451.1426271510@sss.pgh.pa.us
