Re: postgres_fdw join pushdown (was Re: Custom/Foreign-Join-APIs)
От | Ashutosh Bapat |
---|---|
Тема | Re: postgres_fdw join pushdown (was Re: Custom/Foreign-Join-APIs) |
Дата | |
Msg-id | CAFjFpRfgCV8ZsHgch20nfkJN4qgDcPFHhGPsT6P7hg0G_U3f1A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: postgres_fdw join pushdown (was Re: Custom/Foreign-Join-APIs) (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>) |
Ответы |
Re: postgres_fdw join pushdown (was Re:
Custom/Foreign-Join-APIs)
|
Список | pgsql-hackers |
On Tue, Feb 16, 2016 at 12:26 PM, Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp> wrote:
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.
-- 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
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
В списке pgsql-hackers по дате отправления: