Re: postgres_fdw join pushdown (was Re: Custom/Foreign-Join-APIs)

From: Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>
To: Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Jeevan Chalke <jeevan(dot)chalke(at)enterprisedb(dot)com>, Thom Brown <thom(at)linux(dot)com>, "pgsql-hackers(at)postgreSQL(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Shigeru Hanada <shigeru(dot)hanada(at)gmail(dot)com>
Subject: Re: postgres_fdw join pushdown (was Re: Custom/Foreign-Join-APIs)
Date: 2016-02-18 10:18:59
Message-ID: 56C59A93.7050101@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2016/02/16 16:40, Etsuro Fujita wrote:
> On 2016/02/16 16:02, Ashutosh Bapat wrote:
>> On Tue, Feb 16, 2016 at 12:26 PM, Etsuro Fujita
>> <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp <mailto:fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)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.

> Agreed.

>> 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.

> Sorry, I don't understand this fully.

Another thing I don't really understand is why list_copy is needed in
the second list_concat for the case of INNER/FULL JOIN or in both
list_concats for the case of LEFT/RIGHT JOIN, in your patch. Since
list_concat is nondestructive of its second argument, I don't think
list_copy is needed in any such list_concat. Maybe I'm missing
something, though.

Best regards,
Etsuro Fujita

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andreas Joseph Krogh 2016-02-18 10:22:13 Re: JDBC behaviour
Previous Message Dean Rasheed 2016-02-18 10:05:23 Re: custom function for converting human readable sizes to bytes