Re: Foreign join pushdown vs EvalPlanQual - Mailing list pgsql-hackers

From Etsuro Fujita
Subject Re: Foreign join pushdown vs EvalPlanQual
Date
Msg-id 560A024A.7010200@lab.ntt.co.jp
Whole thread Raw
In response to Re: Foreign join pushdown vs EvalPlanQual  (Kouhei Kaigai <kaigai@ak.jp.nec.com>)
Responses Re: Foreign join pushdown vs EvalPlanQual  (Kouhei Kaigai <kaigai@ak.jp.nec.com>)
Re: Foreign join pushdown vs EvalPlanQual  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On 2015/09/29 9:13, Kouhei Kaigai wrote:
>> -----Original Message-----
>> From: pgsql-hackers-owner@postgresql.org
>> [mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Robert Haas
>> Sent: Tuesday, September 29, 2015 5:46 AM
>> To: Kaigai Kouhei(海外 浩平)
>> Cc: Etsuro Fujita; PostgreSQL-development; 花田茂
>> Subject: Re: [HACKERS] Foreign join pushdown vs EvalPlanQual
>>
>> On Mon, Sep 28, 2015 at 3:34 AM, Kouhei Kaigai <kaigai@ak.jp.nec.com> wrote:
>>> The attached patch allows FDW driver to handle EPQ recheck by its own
>>> preferable way, even if it is alternative local join or ExecQual to
>>> the expression being pushed down.

Thanks for the work, KaiGai-san!

>> Thanks.  I was all set to commit this, or at least part of it, when I
>> noticed that we already have an FDW callback called RefetchForeignRow.
>> We seem to be intending that this new callback should refetch the row
>> from the foreign server and verify that any pushed-down quals apply to
>> it.  But why can't RefetchForeignRow do that?  That seems to be what
>> it's for.

Thanks for the comments, Robert!

I thought the same thing [1].  While I thought it was relatively easy to 
make changes to RefetchForeignRow that way for the foreign table case 
(scanrelid>0), I was not sure how hard it would be to do so for the 
foreign join case (scanrelid==0).  So, I proposed to leave that changes 
for 9.6.  I'll have a rethink on this issue along the lines of that 
approach.

Sorry for having had no response.  I was on vacation.

Best regards,
Etsuro Fujita

[1] http://www.postgresql.org/message-id/55DEB5A9.8010604@lab.ntt.co.jp




pgsql-hackers by date:

Previous
From: "Joshua D. Drake"
Date:
Subject: Re: No Issue Tracker - Say it Ain't So!
Next
From: Pavel Stehule
Date:
Subject: ToDo: possibility to set sqlcode, detail, hint in elog like functions in plpython and plperl