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