Re: Foreign join pushdown vs EvalPlanQual

From: Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>
To: Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, 花田茂 <shigeru(dot)hanada(at)gmail(dot)com>
Subject: Re: Foreign join pushdown vs EvalPlanQual
Date: 2015-09-29 03:15:22
Message-ID: 560A024A.7010200@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2015/09/29 9:13, Kouhei Kaigai wrote:
>> -----Original Message-----
>> From: pgsql-hackers-owner(at)postgresql(dot)org
>> [mailto:pgsql-hackers-owner(at)postgresql(dot)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(at)ak(dot)jp(dot)nec(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2015-09-29 03:45:53 ToDo: possibility to set sqlcode, detail, hint in elog like functions in plpython and plperl
Previous Message Joshua D. Drake 2015-09-29 03:08:50 Re: No Issue Tracker - Say it Ain't So!