Re: Foreign join pushdown vs EvalPlanQual

From: Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>
To: Robert Haas <robertmhaas(at)gmail(dot)com>, Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com>
Cc: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, "tgl(at)sss(dot)pgh(dot)pa(dot)us" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, "shigeru(dot)hanada(at)gmail(dot)com" <shigeru(dot)hanada(at)gmail(dot)com>
Subject: Re: Foreign join pushdown vs EvalPlanQual
Date: 2015-12-02 09:22:56
Message-ID: 565EB870.1060700@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2015/12/02 1:54, Robert Haas wrote:
> On Fri, Nov 27, 2015 at 1:25 AM, Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com> wrote:
>>> Sorry, I don't understand this. In my understanding, fdw_recheck_quals
>>> can be defined for a foreign join, regardless of the join type,

>> Yes, "can be defined", but will not be workable if either side of
>> joined tuple is NULL because of outer join. SQL functions returns
>> NULL prior to evaluation, then ExecQual() treats this result as FALSE.
>> However, a joined tuple that has NULL fields may be a valid tuple.
>>
>> We don't need to care about unmatched tuple if INNER JOIN.

> This is a really good point, and a very strong argument for the design
> KaiGai has chosen here.

Maybe my explanation was not enough. Sorry about that. But I mean that
we define fdw_recheck_quals for a foreign-join as quals that 1) were
extracted by extract_actual_join_clauses as "otherclauses"
(rinfo->is_pushed_down=true) and that 2) were pushed down to the remote
server, not scan quals relevant to all the base tables invoved in the
foreign-join. So in this definition, I think fdw_recheck_quals for a
foreign-join will be workable, regardless of the join type.

Best regards,
Etsuro Fujita

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Petr Jelinek 2015-12-02 10:38:27 Re: pglogical_output - a general purpose logical decoding output plugin
Previous Message Shulgin, Oleksandr 2015-12-02 09:20:11 Re: More stable query plans via more predictable column statistics