On 2015/09/02 23:30, Tom Lane wrote: > Etsuro Fujita <fujita.ets...@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.1426271...@sss.pgh.pa.us -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
