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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
