On Tue, Feb 16, 2016 at 12:26 PM, Etsuro Fujita <fujita.ets...@lab.ntt.co.jp > wrote:
> On 2016/02/16 15:22, Ashutosh Bapat wrote: > >> During join planning, the planner tries multiple combinations of joining >> relations, thus the same base or join relation can be part of multiple >> of combination. Hence remote_conds or joinclauses will get linked >> multiple times as they are bidirectional lists, thus breaking linkages >> of previous join combinations tried. E.g. while planning A join B join C >> join D planner will come up with combinations like A(B(CD)) or (AB)(CD) >> or ((AB)C)D etc. and remote_conds from A will first be linked into >> A(B(CD)), then AB breaking the first linkages. >> > > Exactly, but I don't think that that needs to be considered because we > have this at the beginning of postgresGetGForeignJoinPaths: > > /* > * Skip if this join combination has been considered already. > */ > if (joinrel->fdw_private) > return; > > There will be different joinrels for A(B(CD)) and (AB) where A's remote_conds need to be pulled up. The check you have mentioned above only protects us from adding paths multiple times to (AB) when we encounter it for (AB)(CD) and ((AB)C)D. -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company
