Re: Foreign join pushdown vs EvalPlanQual

On 2015/07/06 9:42, Kouhei Kaigai wrote:
>>> Also, I don't want to stick on the assumption that relations involved in
>>> remote join are all managed by same foreign-server no longer.
>>> The following two ideas introduce possible enhancement of remote join
>>> feature that involved local relations; replicated table or transformed
>>> to VALUES() clause.

>>> I think add_paths_to_joinrel() is the best location for foreign-join,
>>> not only custom-join. Relocation to standard_join_search() has larger
>>> disadvantage than its advantage.

>> I agree with you that it's important to ensure the expandability, and my
>> question is, is it possible that the API call from standard_join_search
>> also realize those idea if FDWs can get the join information through the
>> root or something like that?

> I don't deny its possibility, even though I once gave up to implement to
> reproduce join information - which relations and other ones are joined in
> this level - using PlannerInfo and RelOptInfo.

OK

> However, we need to pay attention on advantages towards the alternatives.
> Hooks on add_paths_to_joinrel() enables to implement identical stuff, with
> less complicated logic to reproduce left / right relations from RelOptInfo
> of the joinrel. (Note that RelOptInfo->fdw_private enables to avoid path-
> construction multiple times.)
> I'm uncertain why this API change is necessary to fix up the problem
> around EvalPlanQual.

Yeah, maybe we wouldn't need any API change.  I think we would be able 
to fix this by complicating add_path as you pointed out upthread.  I'm 
not sure that complicating it is a good idea, though.  I think that it 
might be possible that the callback in standard_join_search would allow 
us to fix this without complicating the core path-cost-comparison stuff 
such as add_path.  I noticed that what I proposed upthread doesn't work 
properly, though.

Actually, I have another concern about the callback location that you 
proposed; that might meaninglessly increase planning time in the 
postgres_fdw case when using remote estimates, which the proposed 
postgres_fdw patch doesn't support currently IIUC, but I think it should 
support that.  Let me explain about that.  If you have A JOIN B JOIN C 
all on the same foreign server, for example, we'll have only to perform 
a remote EXPLAIN for A-B-C for the estimates (when adopting a strategy 
that we push down a join as large as possible into the remote server). 
However, ISTM that the callback in add_paths_to_joinrel would perform 
remote EXPLAINs not only for A-B-C but for A-B, A-C and B-C according to 
the dynamic programming algorithm.  (Duplicated remote EXPLAINs for 
A-B-C can be eliminated using a way you proposed.)  Thus the remote 
EXPLAINs for A-B, A-C and B-C seem to me meaningless while incurring 
performance degradation in query planning.  Maybe I'm missing something, 
though.

Best regards,
Etsuro Fujita