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.
So I still think that the most directly useful infrastructure here
would involve, when build_join_rel() first creates a given joinrel,
noticing whether both sides belong to the same foreign server and
if so giving the FDW a callback to consider producing pushed-down
joins. That would be extremely cheap to do and it would not involve
adding overhead for an FDW to discover what the valid sets of joins
are. In a large join problem, that's *not* going to be a cheap
thing to duplicate. If there are multiple FDWs involved, the idea
that each one of them would do its own join search is particularly
horrid.
One other problem with the proposal is that we might never call
standard_join_search at all: GEQO overrides it, and so can external
users of join_search_hook.
regards, tom lane
